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 -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
