We dropped these in 47740802 (specs-go/config: Drop "this field is
platform dependent", 2016-09-14, #568) but f9e48e00 (Windows: User
struct changes, 2016-09-14, #565) was developed in parallel and
brought in a new one.
Signed-off-by: W. Trevor King <wking@tremily.us>
These comments first landed in 820131db (*: flatten platform dependent
source, 2016-03-08, #310). But you can tell they're platform
dependent by the platform:"..." tags. The Go comment doesn't add
any additional information.
Signed-off-by: W. Trevor King <wking@tremily.us>
There are other APIs described in this specification (e.g. the state
JSON format, and the in-flight command-line API [1]), but this string
covers the configuration file and referenced objects (e.g. the
filesystem at root.path). As additional, backwards compatible
features are added to the spec (leading to 1.1, 1.2, etc. releases)
and supported by runtimes, those runtimes will *still* stupport 1.0
configs. Once a 2.0 spec is cut, runtimes that only support 2.0 (and
nothing in the 1.0 line) will no longer support the 1.0 config.
My preferred approach here would be to use JSON-LD [2,3,4] to
explicitly document the intended semantics for each field, which would
allow us to drop the config-wide version and version each field
independently. That would mean a breaking change on a particular
field would only break compatibility for folks who were using that
field. Unfortunately, I haven't had much luck pushing the consensus
in that direction.
This commit does not add wording about how the runtime and other
consumers should handle an incompatible version. We can address that
once the command-line API lands.
[1]: https://github.com/opencontainers/runtime-spec/pull/513
[2]: https://github.com/opencontainers/runtime-spec/pull/371#issuecomment-209684002
[3]: https://github.com/opencontainers/image-spec/pull/111#discussion_r65619280
[4]: https://github.com/opencontainers/runtime-spec/pull/510#discussion_r68513241
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>
With dash 0.5.7:
# make docs
/bin/sh: 1: test: 1.3.3: unexpected operator
/bin/sh: 1: test: 1.3.3: unexpected operator
/bin/sh: 1: test: 1.3.3: unexpected operator
Makefile:47: *** cannot build output//oci-runtime-spec.pdf without either pandoc or docker. Stop.
# command -V test
test is a shell builtin
POSIX defines '=' for string comparison [1]; the '==' form is a
Bashism.
SHELL was added in f3fdf03 (Makefile: prefer bash, 2016-05-25, #455)
to avoid these "unexpected operator" errors, but there's no reason to
require Bash when we can make the comparison's POSIX compliant.
[1]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
Signed-off-by: W. Trevor King <wking@tremily.us>
Since [1] we've required runtimes to error out if a configuration
joins an existing namespace and adjusts it somehow (e.g. joining an
existing UTC namespace and setting 'hostname', [2]). However, the
wording from [1] (which survives untouched in the current master) only
talked about "when a path is specified". I see two possible
approaches for internal consistency:
a. Lift the OCI restriction and allow join-and-tweak [3] where the
kernel supports it. When we landed the current restriction, the
main issues seemed to be "we don't have a clear use-case for join
and tweak" [4] (although see [5]) and "this is a foot gun [6,7]"
(I'd rather leave policy to higher-level config linters).
b. Extend the OCI restriction to all cases where the runtime does not
create a new namespace. Besides the already covered "namespace
entry exists and includes 'path'", we'd also want to forbid configs
that were missing the relevant namespace(s) entirely (in which case
the container inherits the host namespace(s)).
I'm partial to (a) in the long run, but (b) is less of a shift from
the current spec and likely a better choice for a pending 1.0.
This commit implements (b).
It also makes it explicit that not listing a namespace type will cause
the container to inherit the runtime namespace of that type.
[1]: https://github.com/opencontainers/runtime-spec/pull/158
Subject: Clarify behavior around namespaces paths
[2]: https://github.com/opencontainers/runtime-spec/pull/214
Subject: config: Require a new UTS namespace for config.json's hostname
[3]: https://github.com/opencontainers/runtime-spec/pull/158#issuecomment-138687129
[4]: https://github.com/opencontainers/runtime-spec/pull/158#issuecomment-138997548
[5]: https://github.com/opencontainers/runtime-spec/pull/305
Subject: [Tracker] Live Container Updates
[6]: https://github.com/opencontainers/runtime-spec/pull/158#issuecomment-139106987
[7]: https://github.com/opencontainers/runtime-spec/issues/537#issuecomment-242132288
Subject: [linux] Tweaking host namespaces?
Signed-off-by: W. Trevor King <wking@tremily.us>
Jonathan Boulle
Vincent Batts
John Howard
W. Trevor King
Tianon Gravi
Ma Shimiao
Mrunal Patel
Michael Crosby
Doug Davis
Rob Dolin (MSFT)
Qiang Huang
James Hunt
Mrunal Patel
Lei Jitang