config-linux: Extend no-tweak requirement to runtime namespaces #538
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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]: opencontainers#158 Subject: Clarify behavior around namespaces paths [2]: opencontainers#214 Subject: config: Require a new UTS namespace for config.json's hostname [3]: opencontainers#158 (comment) [4]: opencontainers#158 (comment) [5]: opencontainers#305 Subject: [Tracker] Live Container Updates [6]: opencontainers#158 (comment) [7]: opencontainers#537 (comment) Subject: [linux] Tweaking host namespaces? Signed-off-by: W. Trevor King <wking@tremily.us>
This was referenced Aug 24, 2016
|
LGTM |
1 similar comment
|
LGTM |
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Aug 26, 2016
There are more background references for the Linux-namespaces no-tweaking rule in 01c2d55 (config-linux: Extend no-tweak requirement to runtime namespaces, 2016-08-24, opencontainers#538). But the old rule's: > ... error out if the config specifies anything else related to that > namespace. was overly broad. For example, it arguably blocked you from setting network interface priorities for interfaces belonging to an old network namespace even if you were setting those priorities in a new cgroup (because the interfaces and therefore priorities for them are related to the old network namespace). The new rule tries to apply the spirit of the old rule ("don't touch things that already exist") more generally so we have a consistent approach that clearly *does* allow you to configure a new cgroup without having to care about new/old namespaces. I'm personally fine with join-and-tweak, but the maintainer consensus is that it's too complicated to allow (at least for now) [1,2]. [1]: opencontainers#158 Subject: Clarify behavior around namespaces paths [2]: opencontainers#537 (comment) Subject: [linux] Tweaking host namespaces? Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Jan 11, 2017
This restriction originally landed via 02b456e (Clarify behavior around namespaces paths, 2015-09-08, opencontainers#158). The hostname case landed via 66a0543 (config: Require a new UTS namespace for config.json's hostname, 2015-10-05, opencontainers#214) citing the namespace restriction. The restriciton extended to runtime namespaces in 01c2d55 (config-linux: Extend no-tweak requirement to runtime namespaces, 2016-08-24, opencontainers#538). There was a proposal in-flight to get config-wide consistency around the no-tweaking concept [1]. In today's meeting, the maintainer consensus was to strike the no-tweaking restriction [2], which is what I've done here. The hostname entry still mentions the UTS namespace to provide a guard against accidental foot-gunning. There was no no-tweaking language for properties related to other namespaces (e.g. 'mounts'). Maybe the other namespaces have more obvious names. [1]: opencontainers#540 [2]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2017/opencontainers.2017-01-11-22.04.log.html#l-117 Signed-off-by: W. Trevor King <wking@tremily.us>
wking
added a commit
to wking/opencontainer-runtime-spec
that referenced
this pull request
Jan 11, 2017
This restriction originally landed via 02b456e (Clarify behavior around namespaces paths, 2015-09-08, opencontainers#158). The hostname case landed via 66a0543 (config: Require a new UTS namespace for config.json's hostname, 2015-10-05, opencontainers#214) citing the namespace restriction. The restriciton extended to runtime namespaces in 01c2d55 (config-linux: Extend no-tweak requirement to runtime namespaces, 2016-08-24, opencontainers#538). There was a proposal in-flight to get config-wide consistency around the no-tweaking concept [1]. In today's meeting, the maintainer consensus was to strike the no-tweaking restriction [2], which is what I've done here. I've removed the ROADMAP entry because this gives folks a way to adjust existing containers (launch a new container which joins and tweaks the original). The hostname entry still mentions the UTS namespace to provide a guard against accidental foot-gunning. There was no no-tweaking language for properties related to other namespaces (e.g. 'mounts'). Maybe the other namespaces have more obvious names. [1]: opencontainers#540 [2]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2017/opencontainers.2017-01-11-22.04.log.html#l-117 Signed-off-by: W. Trevor King <wking@tremily.us>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implement (b) from #537. Also make it explicit that not listing a
namespace type will cause the container to inherit the runtime
namespace of that type. More details in the commit message, although
that mostly summarizes the discussion from #537.