Open Stack

On Mon, May 11, 2015 at 10: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).



Magnum is clearly geared toward greenfield development.

The Docker driver's sweet-spot is for the user wishing to replace existing
VMs and Nova orchestration with high-performance containers without having
to rewrite for Magnum, or having to deal with the complexities or
hardware-specific bits of Ironic (plus having a tad bit more security). As
an Ironic alternative, it may have a promising long-term life. As for a
mechanism for providing legacy migrations... the future is less clear.
Greenfield applications will go straight to Magnum or non-OpenStack
solutions while the number of legacy applications to be migrated from
nova-libvirt/xen/vmware to nova-docker is unknowable. However, I do expect
it to be a number likely to swell, then diminish as time goes on. Arguably,
the same could be presumed about VMs, however.

It's also worth noting that LXD is pushing to be a container-like-a-VM
solution, so support for building tools to provide legacy VM to container
migrations must be of interest to somebody.



>
>
> 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".
>  - Do we have a team of people willing and able to commit to
>    maintaining it in Nova - ie we don't just want it to bitrot
>    and have nova cores left to pick up the pieces whenever it
>    breaks.
>
>
The two reasons I have preferred this code stay out of tree (until now) has
been the breaking changes we wished to land, and the community involvement.
This driver was not the first driver I've been involved with that has had
these problems, and ultimately I had wished development were out of tree.
Having the code out of tree has been very good for nova-docker.

However, I believe that the period of high-frequency changes over, with
many of the critical goals reached... but that calls into question your
second point, which is the level of continued maintenance. To this, I
cannot answer, but I will say that the team right now is vanishingly small,
 I do wish it were larger. I give a lot of credit to Dims in particular for
keeping this afloat, but this effort needs more contributors if it is to
stay alive. As for myself, for the record, I am seldom involved at this
point, but do contribute some occasional time into reviews or the odd patch
in my free time.

I'll finish to say that I do think it's finally time to consider pulling it
back it.  While doing so may not attract contributors, I know being in
stackforge has certainly been a deterrent both potential contributors and
users.

Regards,
Eric Windisch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150511/fd06ae36/attachment.html>