mesos-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Klues (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (MESOS-6464) Add fine grained control of which namespaces a nested container should inherit (or not).
Date Wed, 09 Nov 2016 00:30:58 GMT

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

Kevin Klues updated MESOS-6464:
-------------------------------
    Summary: Add fine grained control of which namespaces a nested container should inherit
(or not).  (was: Add fine grained control of which namespaces / cgroups a nested container
should inherit (or not).)

> Add fine grained control of which namespaces 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)

Mime
View raw message