From 766abd6f (runtime.md: Require 'create' to fail if config.json
asks for the impossible, 2016-09-08, #559).
Signed-off-by: W. Trevor King <wking@tremily.us>
All of these sections are about configuration, and we don't usually
use "{Whatever} configuration" in the headers.
Signed-off-by: W. Trevor King <wking@tremily.us>
We don't want to silently ignore settings that we understand but
cannot implement [1] (we *do* want to ignore settings that we don't
understand [2], but that's a separate issue).
This raises a slightly sticky certification issue. If a runtime
*always* exits 'create' with an error:
func create() err {
return fmt.Errorf("nope, I cannot create that container either.")
}
it would be neither complaint nor non-compliant. It would not fail
any MUSTs, but availing itself of the "cannot create the maintainer"
option specified in this commit would mean the test suite could not
test the deeper requirements around the config properties themselves.
So with this change, making Microsoft certifiable will still need an
explicit weakening around root.path. The easiest way to do that might
be to have separate annotations for whether a setting is optional for
config authors and whether it's optional for runtime authors
(supported):
* **`readonly`** (bool, config:optional, support:optional) ...
But I'll leave hashing that out to a later commit. Regardless of the
certification impact, we want to be clear that silently ignoring known
parameters is wrong.
[1]: 9b8e21826c (r65400731)
Subject: [ Config | Root Config ] Clarify readonly
[2]: https://github.com/opencontainers/runtime-spec/pull/510
Subject: Add text about extensions
Signed-off-by: W. Trevor King <wking@tremily.us>
There's an outside change that these are intentional, since I pointed
one of these out earlier [1] and it wasn't fixed. But I haven't seen
" : " used intentionally outside of this project, and don't think we
want to break ground in that direction ;).
[1]: https://github.com/opencontainers/runtime-spec/pull/510#discussion_r77291554
Signed-off-by: W. Trevor King <wking@tremily.us>
We use both forms, but the latter was more popular. Before this
branch:
$ git grep -i 'container process' origin/master | wc -l
13
$ git grep -i 'main process' origin/master | wc -l
4
Also fix "process id" -> "process ID" in one of the lines I touched,
to match fork(2) [1].
[1]: http://man7.org/linux/man-pages/man2/fork.2.html
Signed-off-by: W. Trevor King <wking@tremily.us>
The indentation of the sub bullets for the status entries under State were not
indented by the 4 spaces required by markdown. They did not render well in
the pdf, at least with my native build with pandoc v1.13.2. Change them to 4
spaces, which now renders well.
Signed-off-by: Graham Whaley <graham.whaley@linux.intel.com>
Make it clear that if a runtime cannot set up an environment that
*precisely* matches the config.json provided, it must generate an error.
This is important because not doing this can cause security issues.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
The shorter-than-normal (for the rest of this list) indent landed with
the line in be594153 (Split create and start, 2016-04-01, #384).
Signed-off-by: W. Trevor King <wking@tremily.us>
Restore the line removed by be594153 (Split create and start,
2016-04-01, #384). Without this, GitHub renders the list as a single
paragraph.
Signed-off-by: W. Trevor King <wking@tremily.us>
This wording is descended from 7117ede7 (Expand on the definition of
our ops, 2015-10-13, #225), but the idea is covered generically by
e53a72b (Clarify the operation is not for command-line api,
2016-05-24, #450), so we no longer need a create-specific note.
Especially in the lifecycle docs, where there's already enough going
on without this low-level detail.
Signed-off-by: W. Trevor King <wking@tremily.us>
The `Errors` section is more like a general description about
runtime, if it's a sub-section of `Operations`, it'll be hard
for both implementations and tests to define what this
`errors` operation really is.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
This spec places RFC-2119 requirements on both bundles (bundle.md,
config.md, ...) and runtimes (runtime.md, runtime-linux.md). While
it's possible to envision a system where bundle validation is required
before container setup begins, it is also possible to decoupled
validation and allow the runtime to blindly stumble through as far as
it can.
We already link to ocitools and OCT for testing both runtimes and
bundles [1], so users interested in pre-start validation can use those
tools.
This commit explicitly documents the non-requirement and links to
those tools, to make life less surprising for everybody.
[1]: https://github.com/opencontainers/runtime-spec/blob/v0.5.0/implementations.md#testing--tools
Signed-off-by: W. Trevor King <wking@tremily.us>
This slipped through the renumbering in 7117ede7 (Expand on the
definition of our ops, 2015-10-13, #225).
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 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>