<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 11, 2015 at 10:06 AM, Dan Smith <span dir="ltr"><<a href="mailto:dms@danplanet.com" target="_blank">dms@danplanet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> +1 Agreed nested containers are a thing. Its a great reason to keep<br>
> our LXC driver.<br>
<br>
</span>I don't think that's a reason we should keep our LXC driver, because you<br>
can still run containers in containers with other things. If anything,<br>
using a nova vm-like container to run application-like containers inside<br>
them is going to beg the need to tweak more detailed things on the<br>
vm-like container to avoid restricting the application one, I think.<br>
<br>
IMHO, the reason to keep the seldom-used, not-that-useful LXC driver in<br>
nova is because it's nearly free. It is the libvirt driver with a few<br>
conditionals to handle different things when necessary for LXC. The<br>
docker driver is a whole other nova driver to maintain, with even less<br>
applicability to being a system container (IMHO).</blockquote><div><br></div><div><div><br class="">Magnum is clearly geared toward greenfield development.</div></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><br></span><blockquote><span class=""><br></span>I think this is likely the case and I'd like to avoid getting into this<br>
situation again. IMHO, this is not our target audience, it's very much<br>
not free to just put it into the tree because "meh, some people might<br>
like it instead of the libvirt-lxc driver".<br><span style="font-size:12.8000001907349px"> - Do we have a team of people willing and able to commit to<br></span><span style="font-size:12.8000001907349px">   maintaining it in Nova - ie we don't just want it to bitrot<br></span><span style="font-size:12.8000001907349px">   and have nova cores left to pick up the pieces whenever it<br></span><span style="font-size:12.8000001907349px">   breaks.</span></blockquote></blockquote><div> </div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Eric Windisch</div></div></div></div>