On Tue, Jun 18, 2013 at 2:38 PM, Monty Taylor <[email protected]> wrote: > > > On 06/18/2013 05:24 PM, Daniel P. Berrange wrote: >> On Thu, Jun 06, 2013 at 10:33:12AM -0700, Sam Alba wrote: >>> Hi all, >>> >>> I work for dotCloud and I wanted to share our recent work on Nova[1]. >>> We've been using LXC containers on our PaaS product for more than 2 >>> years now and we recently released the Docker project[2] that you may >>> have heard about already. >>> >>> We also wrote a blog post[3] to explain the work we did and how the >>> Glance can make the glue between Nova and Docker's remote Images >>> index. >> >> Some people asked offlist what my opinion was on accepting this new >> virt driver, given that we already have Libvirt LXC driver support >> in Nova. >> >> Superficially this appears to be the same scenario that was recently >> raised wrt supporting a new OpenVZ driver in Nova, vs supporting it >> via the Libvirt OpenVZ capabilities (where we chose the latter). >> >> "LXC" can mean many things. In particular it can refer to the kernel >> features that have been implemented to support containers on Linux >> or it can refer to a specific userspace toolset implementation that >> uses those kernel features. There is the Libvirt LXC driver or there >> is the sf.net LXC toolset providing separate userspace implementations. >> IIUC, Docker is an application that is built on top of the sf.net >> LXC toolset. Conceptually it looks like it works at a higher level >> than the raw LXC toolset, so cannot be considered to duplicate either >> the Libvirt LXC / sf.net LXC toolset, but rather to complement them. >> >> As such, I believe this is a different situation to the one that >> recently arose wrt OpenVZ. A "Docker" driver for Nova would be >> providing integration with different capability, than is provided >> for by the Libvirt LXC driver. So I think there could be merit in >> having Docker support in Nova, provided the submitter (or another >> interested party) is prepared to commit to being an active maintainer >> for the code long term, and not just submit it and expect someone >> else to maintain it after merge. > > I can buy that. I'd also like to add that I think it would be good to > get patches to ensure this driver is tested. Since it's driving LXC, > there should be no problems in doing testing nested in devstack vms.
Thanks for the feedback, it's helpful. I currently work at dotCloud and of course submitting the first version of the driver is just a start for me. I will actively maintain the driver to keep it aligned with the last versions of Docker. I already submitted a code review that I will abandon (since it was not linked to the blueprint). I'll submit the blueprint today and I will re-submit the code on the bp/XXXX branch. It'll be the opportunity to explain the reason behind this work and potentially answer any questions. -- @sam_alba _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
