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 already require it for Linux/Unix-based systems [1], so we don't
have to repeat it here. And other systems will use different paths,
which we haven't specified yet. When I asked why we didn't specify a
path for Windows [2], Vincent said we were waiting on help from PoC
implementations [3]. So this commit punts the location to the "State"
section, and lets the "Lifecycle" section just focus on when the
write-to-filesystem happens.
There's also discussion about removing the filesystem state registry
completely [4], in which case we'd want to remove the whole line from
the lifecycle.
[1]: 7713efc1be (diff-b84a8d65d8ed53f4794cd2db7e8ea731L7)
[2]: https://github.com/opencontainers/specs/pull/211#discussion_r41066673
[3]: https://github.com/opencontainers/specs/pull/211#discussion_r41067134
[4]: https://groups.google.com/a/opencontainers.org/forum/#!topic/dev/q6TYqVZOcX8
Subject: removal of /run/opencontainer/containers
Date: Wed, 25 Nov 2015 14:29:35 +0000
Message-ID: <CAD2oYtNipt3i_C6=J4Bc-jwauo5YAvKXUqTROnPNP3vZ9+C5Vw@mail.gmail.com>
Signed-off-by: W. Trevor King <wking@tremily.us>
The lifecycle described is generic and should apply all platforms.
It provides leeway for the runtimes to be flexible in how they
implement it.
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
we have both styles in the *.md, we should use only one of the styles.
**`name`** is much prettier than **name** in the result,
so we use **`name`**
Signed-off-by: Lai Jiangshan <jiangshanlai@gmail.com>
In an effort to be more discoverable and self-describing change out the
term "oci" for "opencontainer". We should consider using this as the
prefix for global namespaces going forward as oc has conflicts with
existing tools and oci is the name of the initiative not the specs.
This adds runtime state information for oci container's so that it can
be persisted and used by external tools.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
We had an in-person spec discussion, lets separate the spec into some
high-level sections to clarify future discussion.
Crosby agreed to let me merge to master :)