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 <yujie....@gmail.com> 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 <avin...@mesosphere.io>
> wrote:
>
>>
>>
>> On Fri, Sep 16, 2016 at 8:53 PM, Jie Yu <yujie....@gmail.com> 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 <
>>> 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#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

Reply via email to