> > containers should be able to operate even if the parent container goes away
This should never happen. One of the nesting feature is: if the parent container goes way, all its child containers will go away too. The containerizer will enforce it. Reason being that during recovery the containers need to be re-populated in > the `infos` structure. Otherwise there would be descripancy between the > containers present in `infos` before and after recovery. We already have that discrepancy. If a container joining the host network has a rootfs, we'll construct an Info, but we will not recover it. I think we just need to follow the same. In retrospect, we probably should not create 'Info' for that case, we probably should use a different map. We can clean that up later. - Jie On Fri, Sep 16, 2016 at 8:01 PM, Avinash sridharan <[email protected]> wrote: > > > > On Sept. 17, 2016, 1 a.m., Jie Yu wrote: > > > src/slave/containerizer/mesos/isolators/network/cni/cni.cpp, lines > 816-820 > > > <https://reviews.apache.org/r/51871/diff/5/?file=1500794# > file1500794line816> > > > > > > Any reason we need to copy the network files, instead of just > using it? Do we really need to have a containerDir for nested container? I > like the invariant that we only have a containerDir if we actually create > network for the container. > > That is a good point. The only reason I was thinking about maintaining a > copy of each of the network files is that the containers should be able to > operate even if the parent container goes away. This is not an issue for > the MVP, but I was thinking this might be an issue later on when we have > different kill policies enforced. > > That said, after seeing you comment, I am realizing that just copying the > network files is not enough, we need to copy the entire parentDir if we > want to maintain the container operation in the abscene of the parent > container. Which gets complicated. So if we shouldn't worry too much about > this case, then I agree we can just do without using the parent files, and > keep it much simpler. > > Irrespective of whether we use parent's network files, or copy over the > files, I think we still need a `containerDir` for each container. Reason > being that during recovery the containers need to be re-populated in the > `infos` structure. Otherwise there would be descripancy between the > containers present in `infos` before and after recovery. This, I think, > would convolute the logic we would have in `status`, which is critical to > retrieve the container's IP address. > > > - Avinash > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/51871/#review149310 > ----------------------------------------------------------- > > > On Sept. 16, 2016, 11:31 p.m., Avinash sridharan wrote: > > > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > https://reviews.apache.org/r/51871/ > > ----------------------------------------------------------- > > > > (Updated Sept. 16, 2016, 11:31 p.m.) > > > > > > Review request for mesos, Gilbert Song, Jie Yu, Joseph Wu, and Qian > Zhang. > > > > > > Bugs: MESOS-6156 > > https://issues.apache.org/jira/browse/MESOS-6156 > > > > > > Repository: mesos > > > > > > Description > > ------- > > > > The network file setup in the `network/cni` isolator is now nesting > > aware. Since the children share the network and UTS namespace with the > > parent, the network files need to be created only for the parent > > container. For the child containers, the network files will be simply > > a symlink to a parents network files. > > > > > > Diffs > > ----- > > > > src/slave/containerizer/mesos/isolators/network/cni/cni.cpp > 822f11eab5b00c014563322a8c3b2c14cb440e0b > > > > Diff: https://reviews.apache.org/r/51871/diff/ > > > > > > Testing > > ------- > > > > make > > make check > > sudo ./bin/mesos-tests.sh > > > > > > Thanks, > > > > Avinash sridharan > > > > > >
