> 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.
> 
> Jie Yu wrote:
>     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.

Yeah, I see your point. Not very evident from the code. Let me merge the 
`prepare` and `isolate` patches and I will add an explicit comment highlighting 
these cases.


- Avinash


-----------------------------------------------------------
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