This restriction originally landed via 02b456e9 (Clarify behavior
around namespaces paths, 2015-09-08, #158). The hostname case landed
via 66a0543e (config: Require a new UTS namespace for config.json's
hostname, 2015-10-05, #214) citing the namespace restriction. The
restriciton extended to runtime namespaces in 01c2d55f (config-linux:
Extend no-tweak requirement to runtime namespaces, 2016-08-24, #538).
There was a proposal in-flight to get config-wide consistency around
the no-tweaking concept [1].
In today's meeting, the maintainer consensus was to strike the
no-tweaking restriction [2], which is what I've done here. I've
removed the ROADMAP entry because this gives folks a way to adjust
existing containers (launch a new container which joins and tweaks the
original).
The hostname entry still mentions the UTS namespace to provide a guard
against accidental foot-gunning. There was no no-tweaking language
for properties related to other namespaces (e.g. 'mounts').
Maybe the other namespaces have more obvious names.
[1]: https://github.com/opencontainers/runtime-spec/pull/540
[2]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2017/opencontainers.2017-01-11-22.04.log.html#l-117
Signed-off-by: W. Trevor King <wking@tremily.us>
# digest/hashing target
Most of this has spun off with [1], and I haven't heard of anyone
talking about verifying the on-disk filesystem in a while. My
personal take is on-disk verification doesn't add much over serialized
verification unless you have a local attacker (or unreliable disk),
and you'll need some careful threat modeling if you want to do
anything productive about the local attacker case. For some more
on-disk verification discussion, see the thread starting with [2].
# distributable-format target
This spun off with [1].
# lifecycle target
I think this is resolved since 7713efc1 (Add lifecycle for containers,
2015-10-22, #231), which was committed on the same day as the ROADMAP
entry (4859f6da, Add initial roadmap, 2015-10-22, #230).
# container-action target
Addressed by 7117ede7 (Expand on the definition of our ops,
2015-10-13, #225), although there has been additional discussion in
a7a366b3 (Remove exec from required runtime functionalities,
2016-04-19, #388) and 0430aaf1 (Split create and start, 2016-04-01,
#384).
# validation and testing targets
Validation is partly covered by cdcabdeb (schema: JSON Schema and
validator for `config.json`, 2016-01-19, #313) and subequent JSON
Schema work. The remainder of these targets are handled by ocitools
[3].
# printable/compiled-spec target
The bulk of this was addressed by 4ee036fc (*: printable documents,
2015-12-09, #263). Any remaining polishing of that workflow seems
like a GitHub-issue thing and not a ROADMAP thing. And publishing
these to opencontainers.org certainly seems like it's outside the
scope of this repository (although I think that such publishing is a
good idea).
[1]: https://github.com/opencontainers/image-spec
[2]: https://groups.google.com/a/opencontainers.org/d/msg/dev/xo4SQ92aWJ8/NHpSQ19KCAAJ
Subject: OCI Bundle Digests Summary
Date: Wed, 14 Oct 2015 17:09:15 +0000
Message-ID: <CAD2oYtN-9yLLhG_STO3F1h58Bn5QovK+u3wOBa=t+7TQi-hP1Q@mail.gmail.com>
[3]: https://github.com/opencontainers/ocitools
Signed-off-by: W. Trevor King <wking@tremily.us>
Reverting 7232e4b1 (specs: introduce the concept of a runtime.json,
2015-07-30, #88) after discussion on the mailing list [1]. The main
reason is that it's hard to draw a clear line around "inherently
runtime-specific" or "non-portable", so we shouldn't try to do that in
the spec. Folks who want to flag settings as non-portable for their
own system are welcome to do so (e.g. "we will clobber 'hooks' in
bundles we run") are welcome to do so, but we don't have to have
to split the config into multiple files to do that.
There have been a number of additional changes since #88, so this
isn't a pure Git reversion. Besides copy-pasting and the associated
link-target updates, I've:
* Restored path -> destination, now that the mount type contains both
source and target paths again. I'd prefer 'target' to 'destination'
to match mount(2), but the pre-7232e4b1 phrasing was 'destination'
(possibly due to Windows using 'target' for the source?).
* Restored the Windows mount example to its pre-7232e4b1 content.
* Removed required mounts from the config example (requirements landed
in 3848a238, config-linux: specify the default devices/filesystems
available, 2015-09-09, #164), because specifying those mounts in the
config is now redundant.
* Used headers (vs. bold paragraphs) to set off mount examples so we
get link anchors in the rendered Markdown.
* Replaced references to runtime.json with references to config.json.
[1]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/0QbyJDM9fWY
Subject: Single, unified config file (i.e. rolling back specs#88)
Date: Wed, 4 Nov 2015 09:53:20 -0800
Message-ID: <20151104175320.GC24652@odin.tremily.us>
Signed-off-by: W. Trevor King <wking@tremily.us>
We discussed this in the face to face meeting and agreed
that it makes sense to keep the rootfs as is for flexibility.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
W. Trevor King
Vincent Batts
Mrunal Patel
Mrunal Patel
Doug Davis
Swapnil Kulkarni (coolsvap)
Lai Jiangshan
Liang Chenye
Michael Crosby