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>
And mark it omitempty to avoid:
$ ocitools generate --template <(echo '{"linux": {"resources": {}}}') | jq .linux
{
"resources": {
"devices": null
}
}
Signed-off-by: W. Trevor King <wking@tremily.us>
To match the omitempty which the Go property has had since 28cc4239
(add omitempty to 'Device' and 'Namespace', 2016-03-10, #340).
Signed-off-by: W. Trevor King <wking@tremily.us>
I've replaced the old OPTIONAL with our usual:
(<type>, <optional|required>)
to get the property name first, since that translates more directly
into a Go comment that godoc will like.
The new Go comment is much shorter, dropping "unstructured" (because
the Markdown says "structured or unstructured") and "set by external
tools..." (because *everything* in the configuration JSON is set by
external-to-the-runtime tools).
Signed-off-by: W. Trevor King <wking@tremily.us>
The new wording isn't particularly close to either of the old
wordings, but it reads more clearly to me. I've also added our usual:
(<type>, <required|optional>)
to the Markdown so folks can see that this is an optional object
(although see [1] for a more complete version).
[1]: https://github.com/opencontainers/runtime-spec/pull/427
Subject: config: Explicitly list 'hooks' as optional
Signed-off-by: W. Trevor King <wking@tremily.us>
I've replaced the old MAY with our usual
(<type>, <optional|required>)
to get the property name first, since that translates more directly
into a Go comment that godoc will like.
Signed-off-by: W. Trevor King <wking@tremily.us>
I've changed the old "as it is accessible to ..." to the more compact
"as seen by ..." language from the old Markdown version, although I
don't think it's strictly necessary. The original "accessbile to"
language is from 77d44b10 (Update runtime.md, 2015-06-16), which
actually looked fairly similar to the language I'm using here. That
commit's "hostname for the container" lanuage went away in 7ac41c69
(config.md: reformat into a standard style, 2015-06-30), although that
commit made too many changes to motivate them all at that level.
I've left that language out of the Go comment, because truncating for
compact Go comments is fine (the Markdown entry is canonical, and the
Go comment is just to provide some minimal context).
Signed-off-by: W. Trevor King <wking@tremily.us>
I've also added our usual:
(<type>, <required|optional>)
to the Markdown so folks can see that this is a required object.
Signed-off-by: W. Trevor King <wking@tremily.us>
We use both forms, but the latter was more popular. Before this
branch:
$ git grep -i 'container process' origin/master | wc -l
13
$ git grep -i 'main process' origin/master | wc -l
4
Also fix "process id" -> "process ID" in one of the lines I touched,
to match fork(2) [1].
[1]: http://man7.org/linux/man-pages/man2/fork.2.html
Signed-off-by: W. Trevor King <wking@tremily.us>
I've dropped "main process" because "container process" is currently a
much more popular way of identifying that process in this
specification. Before this commit:
$ git grep -i 'main process' | wc -l
4
$ git grep -i 'container process' | wc -l
13
I've also added our usual:
(<type>, <required|optional>)
to the Markdown so folks can see that this is a required object.
Signed-off-by: W. Trevor King <wking@tremily.us>
Don't mention OS and Arch, since they're covered by the list (in
Markdown) and Platform struct (in Go). This gives us one less place
to update if we ever change the schema for the platform object.
Signed-off-by: W. Trevor King <wking@tremily.us>
Catch up with the spec title from faad7e0f (README: title rename,
2016-04-04, #365).
Also make the Go comment consistent with the Markdown spec (no need to
maintain two phrasings for the same idea). The only difference
between the phrasings is now some shuffling at the beginning to start
off with the property name (to keep godoc happy).
The JSON Schema entry (in defs.json) is different too, because it has
to apply to both the configuration and state JSON, so mentioning
"bundle" makes less sense than mentioning "document".
Signed-off-by: W. Trevor King <wking@tremily.us>
Closes#516
PullApprove has support to check for DCO
Also, take the time to improve the approve_regex
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Make explicit that runtimes only have to attach to the bare minimum
number of cgroups in order to fulfil the users' requirements. However,
runtimes are of course allowed to attach to more than the bare minimum.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Clarify some of the confusion with cgroupsPath. Due to systemd, we
cannot require that relative paths be treated in any specific way. In
addition, add a line stating that not all values of cgroupsPath are
required to be valid (and that runtimes must error out if they have an
invalid cgroup path). However, any given value of cgroupsPath should
provide consistent results.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Michael Crosby
Rob Dolin (MSFT)
W. Trevor King
Mrunal Patel
Vincent Batts
Ma Shimiao
Qiang Huang
James Hunt
Mrunal Patel
Lei Jitang
Haiyan Meng
Chris Aniszczyk
Daniel, Dao Quang Minh
Aleksa Sarai