In fact, in MVP, 'status' won't be called for nested containers. Containerizer will enforce that.
On Fri, Sep 16, 2016 at 9:01 PM, Avinash Sridharan <[email protected]> wrote: > > > On Fri, Sep 16, 2016 at 8:53 PM, Jie Yu <[email protected]> wrote: > >> 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. >> >> >> Ok, in that case its my bad. I misunderstood, thinking that in future the > kill policy might allow reincarnation of the parents without killing the > children. So using the parents network files directly should just work. > >> 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. >> >> Ok, for MVP, I will keep the current behavior (with the discrepancy). > Won't create a containerDir for this child containers. Will need to > implement some extra checks in `status` to get correct `ContainerStatus` > for containers not in `infos`, but that should be trivial. > >> - 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#fil >>> e1500794line816> >>> > > >>> > > 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 >>> > >>> > >>> >>> >> > > > -- > Avinash Sridharan, Mesosphere > +1 (323) 702 5245 >
