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