Kevin Klues created MESOS-6464:
----------------------------------
Summary: 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
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)
