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>
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>
Qiang Huang
W. Trevor King
Michael Crosby
Vincent Batts
Mrunal Patel
Rob Dolin (MSFT)
Amit Saha
Abhijeeth Nuthan
Amit Saha