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>
Use wording from config.md, since the JSON Schema doesn't seem like a
good place to be picking new words.
Signed-off-by: W. Trevor King <wking@tremily.us>
The user-namespace restriction isn't about the root filesystem in
particular. For example, if you bind mount in a second filesystem,
the runtime shouldn't adjust ownership on that filesystem either.
I've also adjusted the old "permissions" to "ownership", since that
more clearly reflects the fields (user and group) that you would
modify if you wanted to adjust for user namespacing.
Signed-off-by: W. Trevor King <wking@tremily.us>
This has been stale since cb2da543 (config: Single, unified config
file, 2015-12-28, #284), when we dropped the attempt to distinguish
between platform-independent and platform-dependent configuration.
Signed-off-by: W. Trevor King <wking@tremily.us>
In dc9daf9 (Makefile: Replace vbatts/pandoc with a PANDOC variable
2016-05-06, #428) I'd misunderstood vbatts/pandoc as a call to a
locally-installed pandoc, when it's actually the name of a Docker
image [1,2]. With this commit, we prefer a local pandoc if one
exists, fall back to Docker and vbatts/pandoc if a local 'docker'
exists, and raise an error if neither 'pandoc' nor 'docker' exist.
[1]: https://github.com/opencontainers/runtime-spec/pull/440
[2]: https://github.com/opencontainers/runtime-spec/pull/428#discussion_r63987603
Reported-by: Qiang Huang <h.huangqiang@huawei.com>
Reported-by: Lai Jiangshan <jiangshanlai@gmail.com>
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>
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>
# 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>
Mrunal Patel
Doug Davis
Michael Crosby
W. Trevor King
Qiang Huang
Chris Aniszczyk
Vincent Batts
Rob Dolin (MSFT)