> The container based drivers in libvirt have been a bit of a square-peg / I am that man who will do this work. I think it can be stateless driver like hyperv driver from libvirt. Most of calls to the driver will bring remote call to docker host by native docker API. So my first implementation of docker driver will iclude all
calls those have realized for hyperv driver now.
From: Nikolay Shirokovskiy <nshirokovskiy@xxxxxxxxxxxxx>
Sent: Thursday, April 16, 2020 3:18 PM To: Daniel P. Berrangé <berrange@xxxxxxxxxx> Cc: Martin Kletzander <mkletzan@xxxxxxxxxx>; libvir-list@xxxxxxxxxx <libvir-list@xxxxxxxxxx>; Dmitry Nesterenko <dmitry.nesterenko@xxxxxxxxxxxxx>; Dmitry Mishin <dim@xxxxxxxxxxxxx> Subject: Re: [RFC] Adding docker driver to libvirt Adding to cc again, now keeping mailing list
On 15.04.2020 16:09, Daniel P. Berrangé wrote: > On Tue, Apr 14, 2020 at 09:56:24AM +0300, nshirokovskiy wrote: >> >> >> On 12.04.2020 12:39, Martin Kletzander wrote: >>> On Thu, Apr 09, 2020 at 03:30:11PM +0300, nshirokovskiy wrote: >>>> Hi, all. >>>> >>>> Does it make sense to add such a driver? I can't say I have a big picture >>>> of docker functionality in mind but at least container lifecycle management >>>> and container networking are common to both. >>>> >>> >>> I think we had something in virt-tools that was able to pull an image from >>> docker hub and run it with lxc. Or was it part of sandbox? I don't know. >>> >>> Anyway, what would be the benefit of that? >>> >> >> We wanted to add Windows containers to the libvirt API. They are available >> under docker API thus the idea to add a docker driver. The docker itself >> uses some API to manage Windows containers but this API lacks documentation >> thus again the willingness to use just docker API to bring Windows containers >> to libvirt. > > The container based drivers in libvirt have been a bit of a square-peg / > round-hole thing. Given that we have a couple of them already (LXC, > OpenVZ, VZ), I wouldn't say no to adding a docker one too. The only > real issue is having people willing to do the work to implement it and > then maintain it thereafter. > > Describing the scope of the desired work is probably useful. With docker, > a big part is in the image download/listing/upload and build process. > The container lifecycle is only a small part of the API coverage. The > image parts have no mapping in libvirt, and I'm not sure whether we > should to expand libvirt scope to that too. > > Regards, > Daniel > |
