[jira] [Updated] (MESOS-6464) Add fine grained control of which namespaces / cgroups a nested container should inherit (or not).

["Artem Harutyunyan (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MESOS-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Artem Harutyunyan updated MESOS-6464:
-------------------------------------
    Sprint: Mesosphere Sprint 45, Mesosphere Sprint 46  (was: Mesosphere Sprint 45)

> Add fine grained control of which namespaces / cgroups a nested container should inherit (or not).
> --------------------------------------------------------------------------------------------------
>
>                 Key: MESOS-6464
>                 URL: https://issues.apache.org/jira/browse/MESOS-6464
>             Project: Mesos
>          Issue Type: Task
>            Reporter: Kevin Klues
>            Assignee: Kevin Klues
>              Labels: debugging, mesosphere
>
> We need finer grained control of which namespaces / cgroups a nested container should inherit or not.
> Right now, there are some implicit assumptions about which cgroups we enter and which namespaces we inherit when we launch a nested container. For example, under the current semantics, a nested container will always get a new pid namespace but inherit the network namespace from its parent. Moreover, nested containers will always inherit all of the cgroups from their parent (except the freezer cgroup), with no possiblity of choosing any different configuration.
> My current thinking is to pass the set of isolators to {{containerizer->launch()} that we would like to have invoked as part of launching a new container. Only if that isolator is enabled (via the agent flags) AND it is passed in via {{launch()}, will it be used to isolate the new container (note that both cgroup isolation as well as namespace membership also implemented using isolators).  This is a sort of a whitelist approach, where we have to know the full set of isolators we want our container launched with ahead of time.
> Alternatively, we could consider passing in the set of isolators that we would like *disabled* instead.  This way we could blacklist certain isolators from kicking in, even if they have been enabled via the agent flags.
> In both approaches, one major caveat of this is that it will have to become part of the top-level containerizer API, but it is specific only to the universal containerizer. Maybe this is OK as we phase out the docker containerizer anyway.
> I am leaning towards the blacklist approach at the moment...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)