Open Stack

On 05/11/2015 03:51 PM, Adrian Otto wrote:
> Dan and John,
> 
> On May 11, 2015, at 7:06 AM, Dan Smith <dms at danplanet.com> wrote:
> 
>>> +1 Agreed nested containers are a thing. Its a great reason to keep
>>> our LXC driver.
>>
>> I don't think that's a reason we should keep our LXC driver, because you
>> can still run containers in containers with other things. If anything,
>> using a nova vm-like container to run application-like containers inside
>> them is going to beg the need to tweak more detailed things on the
>> vm-like container to avoid restricting the application one, I think.
>>
>> IMHO, the reason to keep the seldom-used, not-that-useful LXC driver in
>> nova is because it's nearly free. It is the libvirt driver with a few
>> conditionals to handle different things when necessary for LXC. The
>> docker driver is a whole other nova driver to maintain, with even less
>> applicability to being a system container (IMHO).
>>
>>> I am keen we set the right expectations here. If you want to treat
>>> docker containers like VMs, thats OK.
>>>
>>> I guess a remaining concern is the driver dropping into diss-repair
>>> if most folks end up using Magnum when they want to use docker.
>>
>> I think this is likely the case and I'd like to avoid getting into this
>> situation again. IMHO, this is not our target audience, it's very much
>> not free to just put it into the tree because "meh, some people might
>> like it instead of the libvirt-lxc driver”.
> 
> This is a valid point. I do expect that the combined use of Nova +
> (nova-docker | libvirt-lxc) + Magnum will be popular in situations
> where workload consolidation is a key goal, and security isolation is
> a non-goal. For this reason, I’m very interested in making sure that
> we have some choice for decent Nova virt drivers that produce Nova
> instances that are containers. This matters, because Magnum currently
> expects to get all its instances from Nova.
> 
> I do recognize that nova-docker has stabilized to the point where it
> would be practical to maintain it within the Nova tree. As Eric
> Windisch mentioned, the reasons for having this as a separate code
> repo have vanished. It’s feature complete, has and passes the
> necessary tests, and has a low commit velocity now.
> 
> Perhaps our Nova team would feel more comfortable about ongoing
> maintenance if the Magnum team were willing to bring nova-docker into
> its own scope of support so we don’t suffer from orphaned code. If we
> can agree to adopt this from a maintenance perspective, then we
> should be able to agree to have it in tree again, right?
> 
> I have added this to the Containers Team IRC meeting agenda for
> tomorrow. Let’s see what the team thinks about this.
> 
> https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-05-12_1600_UTC
>
>  I invite Nova and nova-docker team members to join us to discuss
> this topic, and give us your input.

If the Magnum team is interested in helping to maintain it, why not just
keep it as a separate repo?  What's the real value in bringing it into
the Nova tree?

It could serve as a good example of how an optional nova component can
continue be maintained in a separate repo.

-- 
Russell Bryant