> On Sept. 19, 2016, 11:43 p.m., Jie Yu wrote:
> > src/slave/containerizer/mesos/isolators/network/cni/cni.cpp, lines 666-668
> > <https://reviews.apache.org/r/51857/diff/4/?file=1500782#file1500782line666>
> >
> >     Do we need a new mount namespace if i just want execute some command on 
> > the host mount table without a rootfs?
> 
> Avinash sridharan wrote:
>     This code is part of the else block, which means that the container is 
> joining a non-host network, implying that it needs its own mount namespace, 
> since the network files will be different than the host network files?
>     
>     This is a child container, so it doesn't need a new NETNS or UTS 
> namespace but it will require a new MNT namespace.

OK, I guess here is a little tricky. For a nested container, the containerizer 
will correctly enter the namespace of its parent container's network namespace 
and UTS namespace. The following cases are possible:
1) The parent container joins the host network, does not have a rootfs
2) The parent container joins the host network, has a rootfs
3) The parent container joins CNI networks, does not have a rootfs
4) The parent contianer joins CNI networks, has a rootfs

For 1), there's no Info associated with the parent container, and I don't think 
we need a mount namespace for child container.
For 2), there's an Info associated with the parent container (only has rootfs 
set). If the child container does not have a rootfs, we don't need a mount 
namespace. If the child container has a rootfs, we need a mount namespace.
For 3), there's an Info (both rootfs and containerNetworks are set). No mather 
if the child has a rootfs or not, we need a mount namespace.
For 4), same as 4)

Better to document the above in the code.

I think the invarient is that: we only create Info for child containers that 
need a new mount namespace.


- Jie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/51857/#review149563
-----------------------------------------------------------


On Sept. 16, 2016, 11 p.m., Avinash sridharan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51857/
> -----------------------------------------------------------
> 
> (Updated Sept. 16, 2016, 11 p.m.)
> 
> 
> Review request for Gilbert Song, Jie Yu, Joseph Wu, and Qian Zhang.
> 
> 
> Bugs: MESOS-6156
>     https://issues.apache.org/jira/browse/MESOS-6156
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Modified the `prepare` method to be aware of nested containers.
> 
> 
> Diffs
> -----
> 
>   src/slave/containerizer/mesos/isolators/network/cni/cni.cpp 
> 822f11eab5b00c014563322a8c3b2c14cb440e0b 
> 
> Diff: https://reviews.apache.org/r/51857/diff/
> 
> 
> Testing
> -------
> 
> make 
> make check
> and
> sudo ./bin/mesos-tests.sh
> 
> The only tests that failed were the SUDO make check tests:
> [  FAILED  ] 3 tests, listed below:
> [  FAILED  ] CgroupsAnyHierarchyWithCpuMemoryTest.ROOT_CGROUPS_Listen
> [  FAILED  ] CgroupsAnyHierarchyMemoryPressureTest.ROOT_IncreaseRSS
> [  FAILED  ] LinuxFilesystemIsolatorTest.ROOT_RecoverOrphanedPersistentVolume
> 
> 
> Thanks,
> 
> Avinash sridharan
> 
>

Reply via email to