Open Stack

On Tue, Jun 18, 2013 at 2:38 PM, Monty Taylor <mordred at inaugust.com> 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