[linux] Tweaking host namespaces? #537
Comments
|
No this is too split brained. You either create a new one and fulfill the settings that the user requested or you join a pre-created namespace that is complete. We don't want a mix of the two. |
|
On Wed, Aug 24, 2016 at 09:45:51AM -0700, Michael Crosby wrote:
This sounds like “we should implement (b)” (which I agree makes more |
|
No we should not touch host namespaces |
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 <[email protected]>
|
On Wed, Aug 24, 2016 at 10:02:04AM -0700, Michael Crosby wrote:
That's (b), and not what the current spec says. I've opened #538 with |
|
#538 has been merged. |
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 <[email protected]>
Since #158 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, #214). However, the wording from #158 (which survives untouched in the current master) only talks about “when a path is specified”. I expect we want to do one of two things for consistency:a. Lift the OCI restriction and allow join-and-tweak 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” (although see #305) and “this is a foot gun” (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. I'm happy to PR text for either option, although the text itself will likely not be much trouble once we decide which course we want to take ;).
The text was updated successfully, but these errors were encountered: