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.

Nikolay

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?

On Tue, Apr 14, 2020 at 09:56:24AM +0300, nshirokovskiy wrote: > 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. Oh, so with that we would be able to manage native containers on Windows? That might be interesting then. I did not know about that because last time I heard about containers on Windows docker was running a Linux VM in which it spawned the containers =D I did not know there's something new now.

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

> 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.... Hi all! 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.