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>
# 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>
Both fields are optional, so you could conceivably have neither.
However, in most cases folks will populate the one corresponding to
their platform. The one that *doesn't* match their platform must not
show up, in order to avoid violating the:
This should only be set if **`platform.os`** is ...
phrasing.
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>
It's an optional setting, and this change will fix the wordy:
$ ocitools generate --template <(echo '{}')
$ grep readonly config.json
"readonly": false,
Instead, config.json will not contain a 'readonly' entry at all.
Signed-off-by: W. Trevor King <wking@tremily.us>
It's an optional setting, and this change will fix the wordy:
$ ocitools generate --template <(echo '{}')
$ grep terminal config.json
"terminal": false,
Instead, config.json will not contain a 'terminal' entry at all.
Signed-off-by: W. Trevor King <wking@tremily.us>
Defaulting to whichever PANDOC is first in your path. This mirrors
the existing DOCKER handling. Folks who want to use the old path can
run:
$ make PANDOC=vbatts/pandoc ...
I'm not sure why 4ee036fc (*: printable documents, 2015-12-09, #263)
went with a variable for 'docker' but a hard-coded path for 'pandoc'.
I expect it was just oversight.
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>
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>
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>