[
https://issues.apache.org/jira/browse/MESOS-8534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16366504#comment-16366504
]
ASF GitHub Bot commented on MESOS-8534:
---------------------------------------
Github user jieyu commented on a diff in the pull request:
https://github.com/apache/mesos/pull/263#discussion_r168655002
--- Diff: src/slave/containerizer/mesos/isolators/network/cni/cni.cpp ---
@@ -751,10 +751,11 @@ Future<Option<ContainerLaunchInfo>>
NetworkCniIsolatorProcess::prepare(
launchInfo.add_clone_namespaces(CLONE_NEWNET);
launchInfo.add_clone_namespaces(CLONE_NEWNS);
launchInfo.add_clone_namespaces(CLONE_NEWUTS);
+ infos[containerId]->needsSeparateNs = needsSeparateNs;
--- End diff --
I'd just store `joinParentNetwork` boolean in the `Info` struct.
Looks like we need some way to checkpoint this information. Otherwise,
after recovery, how does the isolator tell if it needs to call CNI detach for
nested container? Currently, since nested container always share with its
parent, no need to do any cleanup. But it's no longer true with this change.
But I think we can tell if we discover a nested container having
checkpointed data under `/var/run/mesos/isolators/network/cni/`. See
`src/slave/containerizer/mesos/isolators/network/cni/paths.hpp` for the
checkpointing layout. You'll notice this when you properly implement recover()
method.
> Allow nested containers in TaskGroups to have separate network namespaces
> -------------------------------------------------------------------------
>
> Key: MESOS-8534
> URL: https://issues.apache.org/jira/browse/MESOS-8534
> Project: Mesos
> Issue Type: Task
> Components: containerization
> Reporter: Sagar Sadashiv Patwardhan
> Priority: Minor
> Labels: cni
>
> As per the discussion with [~jieyu] and [~avinash.mesos] , I am going to
> allow nested containers in TaskGroups to have separate namespaces. I am also
> going to retain the existing functionality, where nested containers can share
> namespaces with parent/root container.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
