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