[
https://issues.apache.org/jira/browse/MESOS-6464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15658881#comment-15658881
]
Kevin Klues commented on MESOS-6464:
------------------------------------
{noformat}
commit 0f3eabcfaed5e449988c239d312f17d3b25a04ca
Author: Kevin Klues <[email protected]>
Date: Fri Nov 11 16:14:35 2016 -0800
Removed unnecessary 'parentHooks' parameter from 'Launcher::fork()'.
Review: https://reviews.apache.org/r/53350/
{noformat}
{noformat}
commit 727ce3d4f8b7c6b489a431983666f340398b0c97
Author: Kevin Klues <[email protected]>
Date: Fri Nov 11 16:19:41 2016 -0800
Added 'ContainerClass' to help decide how best to launch a container.
A 'ContainerClass' must now be passed to all *nested*
containerizer->launch() calls in order to specify the class of
container being launched. For now, we simply have the default nested
container class (called 'NESTED') in a subsequent commit we will
introduce the 'DEBUG' class to help classify debug-based nested
containers that should be launched slightly differently than default
nested containers.
The 'ContainerClass' specified is passed through to each isolator in
'ContainerConfig' so they have a chance to custiomize their isolation
policies based on the class as well.
Review: https://reviews.apache.org/r/53351/
{noformat}
{noformat}
commit 329f3ea90ee9b4c49f7a35af76065b19dadedceb
Author: Kevin Klues <[email protected]>
Date: Fri Nov 11 16:20:25 2016 -0800
Updated 'LinuxLauncher->fork()` with *enter* and *clone* namespaces.
Instead of only taking the namespaces to *clone* inside a newly forked
container, 'LinuxLauncher->fork()' now takes a list of namespaces to
enter inside a parent container before forking. When both an *enter*
and a *clone* for the same namespace are passed, we will first enter
the namespace of the parent, and then clone a new one.
Review: https://reviews.apache.org/r/53352/
{noformat}
{noformat}
commit 09d42454c01398e0b7b6588aab4488b68cb82435
Author: Kevin Klues <[email protected]>
Date: Fri Nov 11 16:52:54 2016 -0800
Added proper dependencies on the 'filesystem/linux' isolator.
For some isolators, this meant adding an explicit dependency on
'filesystem/linux' and then removing any of their local calls to
'set_clone_namespaces(CLONE_NEWNS)'. For others, this meant simply
removing their explicit 'set_clone_namespaces(CLONE_NEWNS)' calls
since they are redundant with the one made by 'filesystem/linux'.
The 'cni' isolator is a special case, however, because it may need to
call 'set_clone_namespaces(CLONE_NEWNS)' even if the
'filesystem/posix' isolator is enabled. For this we added a comment.
Review: https://reviews.apache.org/r/53682/
{noformat}
{noformat}
commit a012efa0b57f0199b7ed54b12e9c522d695e09aa
Author: Kevin Klues <[email protected]>
Date: Fri Nov 11 16:53:07 2016 -0800
Introduced a new 'DEBUG' container class.
Review: https://reviews.apache.org/r/53353/
{noformat}
{noformat}
commit 0dafc55529e386e97e6384e1b8e5a19a84899b63
Author: Kevin Klues <[email protected]>
Date: Fri Nov 11 17:01:23 2016 -0800
Updated namespace isolators to customize based on 'ContainerClass'.
The namespace-related isolators now do different things depending on
whether they are launching a "normal" nested container or a "debug"
nested container. Normal nested containers clone a new mount namespace
as well as a new pid namespace. Debug nested cotnainers do not -- they
simply inherit these namespaces from their parent.
Review: https://reviews.apache.org/r/53354/
{noformat}
> 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
> Fix For: 1.2.0
>
>
> 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)
