Ah, that simplifies things. In that case don't think there should be any change to `status`.
On Fri, Sep 16, 2016 at 9:02 PM, Jie Yu <[email protected]> wrote: > 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 >> > > -- Avinash Sridharan, Mesosphere +1 (323) 702 5245
