[ 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)