>
> 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 <avin...@mesosphere.io>
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
> >
> >
>
>

Reply via email to