This slipped through the rename in 2a5986f7 (schema/state-schema.json:
Add a JSON Schema for the state JSON, 2016-06-01, #481) and the first
round of fixes in dfb85b16 (schema/README: Fix links to
(config|state)-schema.json, 2016-06-13, #498). Reported by hapnermw
[1].
[1]: https://github.com/opencontainers/runtime-spec/issues/517
Signed-off-by: W. Trevor King <wking@tremily.us>
This reverts commit 0f25f18b9b, #253.
Now that we're on to 1.0, we don't need to talk about 0.x. And the
lack of 0.x backwards compatability is covered by SemVer 2.0 section 4
[1]:
Major version zero (0.y.z) is for initial development. Anything may
change at any time. The public API should not be considered stable.
so removing the echo from our spec doesn't actually change anything.
The conflict is due to 4e63ee0a (config: qualify the name of the
version field, 2016-01-13, #309), and only impacted the context and
line-wrapping around the sentence I'm removing.
Conflicts:
config.md
[1]: http://semver.org/spec/v2.0.0.html
Signed-off-by: W. Trevor King <wking@tremily.us>
The cgroup namespace is a new kernel feature available in 4.6+ that
allows a container to isolate its cgroup hierarchy. This currently only
allows for hiding information from /proc/self/cgroup, and mounting
cgroupfs as an unprivileged user. In the future, this namespace may
allow for subtree management by a container.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
In the degenerate case where the container does not create a user
namespace, the "container namespace" distinction is unimportant, but
the phrasing is still accurate (the container and runtime namespaces
are the same).
Signed-off-by: W. Trevor King <wking@tremily.us>
The old platform.os text had two MUST conditions. The first could
have been read "the runtime MUST generate an error if invoked with a
config.json whose platform.os is incompatible with the host platform"
(which is the direction I'm going with this commit). However, it
could also have been read "the bundle-validator MUST generate an error
if platform.os is incompatible with the content the bundle's other
content (e.g. 'linux' in platform.os, but only Windows binaries in the
bundle's rootfs).
For the second MUST, I doubt we want to require a compliant runtime
support all Go architectures itself. And there is a benefit to
pointing runtime/bundle authors at the Go set, but not much benefit in
making that a hard limit [1,2]. The rewording here follows [2] in
acknowledging that process.arch-matching is something that the config
author and runtime caller have to sort out between themselves and
pointing them at the Go docs and a registration process to avoid
fragmenting the community.
[1]: https://github.com/opencontainers/image-spec/pull/29
[2]: https://github.com/opencontainers/image-spec/pull/60
Signed-off-by: W. Trevor King <wking@tremily.us>
This was raised during reviews with folks working on Windows Containers.
This squashes commits from PR #433
Signed-off-by: Rob Dolin <RobDolin@microsoft.com>
This should have been part of 759ee79c (config: Add
platform-specific entry for 'solaris', 2016-05-06, #431), since
the example has platform.os set to 'linux'.
There was some (brief) discussion of this point before the 'solaris'
section landed [1], but the "should only be set if" wording landed in
parallel via b373a15 (config: Split platform-specific configuration
into its own section, 2016-05-02, #414), and I'd forgotten to go back
and apply that logic to #411.
Having a full Solaris example would be useful, but I think it should
be a separate, Solaris-only example.
[1]: https://github.com/opencontainers/runtime-spec/pull/411#discussion_r61621001
Signed-off-by: W. Trevor King <wking@tremily.us>
Fixup for 7c9daeb (Introducing Solaris in OCI, 2016-04-25, #411) along
the lines of b373a15 (config: Split platform-specific configuration
into its own section, 2016-05-02, #414).
Signed-off-by: W. Trevor King <wking@tremily.us>
Change made with:
$ sed -i 's/\t/ /g' config.md
fixing tabs that were added with 1c49f4d2 (Add annotations and labels
to the Spec, 2016-03-04, #331).
Signed-off-by: W. Trevor King <wking@tremily.us>
The language from 15dee2e0 (runtime: Add prestart/poststop hooks,
2015-08-03, #34) landed well before we had glossary entries for the
runtime and container namespaces (from 5dad1255, config-linux: Specify
host mount namespace for namespace paths, 2015-12-18, #275). Now that
we do have language to cover that concept, it's better to explicitly
say that hooks run in the runtime namespace instead of leaving it to
the reader to extrapolate from the filesystem requirement.
With the new namespace wording, the "host's filesystem" wording is
somewhat redundant. I've left it in though, because I think it helps
to have a more gradual transition from hook paths to namespaces.
Signed-off-by: W. Trevor King <wking@tremily.us>
* specs-go/config: Make Spec.Mounts omitempty
Otherwise:
$ ocitools generate --mount-cgroups=no --template <(echo {})
$ grep mounts config.json
"mounts": null,
The language in config.md#Mounts is:
> You can add array of mount points...
which I think means 'MAY'.
Signed-off-by: W. Trevor King <wking@tremily.us>
* config: Use 'MAY' (RFC 2119) for mounts
Signed-off-by: W. Trevor King <wking@tremily.us>
To match where they're defined in the JSON Schema [1]. The old
location is from d4e7326d (config: JSON examples, 2016-04-06, #370),
and seems to have been accidental.
[1]: 0982071b28/schema/schema-linux.json (L21-L48)
Signed-off-by: W. Trevor King <wking@tremily.us>
So that runtimes don't lock up forever waiting on a hook to return I
added a timeout field. This allows the author to specify the timeout in
seconds that they want the hook to run before aborting the hook and
container execution.
I think the hook is the proper place to specify a timeouot like this
because any type of overall timeout in the runtime will probably not
work for all hooks and will not be flexable enough.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Also:
* Update the link to Go bindings after 7bf06d5 (source and schema:
differentiate with examples, 2015-12-18, #276).
* Add a reference to the JSON Schema after cdcabde (schema: JSON
Schema and validator for `config.json`, 2016-01-19, #313).
It's pretty clear that the Go bindings cannot be canonical on their
own, because they do not define limits (e.g. the 0 through 512 range
for FileMode). The JSON Schema is closer, but still does not cover
everything (e.g. "a directory must exist at root.path"). Both the Go
bindings and the JSON Schema could grow to cover the full spec by
adding that sort of thing to comments and descriptions, but that's not
how things seem to be working now.
Signed-off-by: W. Trevor King <wking@tremily.us>
The standard is on the JSON schema (not yet IETF spec JSON-schema), such
that it is not implemenations specific. Thus far, the reference has been
in how golang source renders the JSON documents.
Having the JSON source and the markdown documents in sync has been an
ongoing step to keep in sync.
Separating these two allows the golang source to continue being _a_
reference, but the JSON schema in the documentation to be _the_
reference.
As validation tooling is refined, then it will facilitate ensuring
the available golang source conforms to the reference JSON.
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
This moves process specific settings like caps, apparmor, and selinux
process label onto the process structure to allow the same settings to
be changed at exec time.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
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>
Qiang Huang
W. Trevor King
Michael Crosby
Aleksa Sarai
Mrunal Patel
Rob Dolin (MSFT)
Vincent Batts
Abhijeeth Nuthan
Amit Saha
Mrunal Patel
Kenfe-Mickael Laventure
liangchenye
Julian Friedman
Vishnu kannan