[RFC] Adding docker driver to libvirt
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?
Nikolay
On Sun, 2020-04-12 at 11:39 +0200, 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.
This is the virt-bootstrap tool: https://github.com/virt-manager/virt-bootstrap -- Cedric
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. Nikolay
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.
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.
Nikolay
On Tue, 2020-04-14 at 18:34 +0200, Martin Kletzander wrote:
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.
Note that we don't build the daemon on Windows, so this would have to be a stateless driver. I think that's probably fine, since Docker already has its own daemon which supports remote connections (see DOCKER_HOST in [1]). [1] https://docs.docker.com/engine/reference/commandline/cli/#environment-variab... -- Andrea Bolognani / Red Hat / Virtualization
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 :|
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
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. Dmitry ________________________________ From: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com> Sent: Thursday, April 16, 2020 3:18 PM To: Daniel P. Berrangé <berrange@redhat.com> Cc: Martin Kletzander <mkletzan@redhat.com>; libvir-list@redhat.com <libvir-list@redhat.com>; Dmitry Nesterenko <dmitry.nesterenko@virtuozzo.com>; Dmitry Mishin <dim@virtuozzo.com> 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
On Thu, Apr 16, 2020 at 01:47:39PM +0000, Dmitry Nesterenko wrote:
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.
What format does the API take ? Is it a plain REST API we will call via the existing libcurl dependancy in libvirt ? 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 :|
What format does the API take ? Is it a plain REST API we will call via the existing libcurl dependancy in libvirt ? Yes of course. It is just what I think - plain REST API by https requests and already existing in project libcurl. Dmitry ________________________________ From: Daniel P. Berrangé <berrange@redhat.com> Sent: Thursday, April 16, 2020 4:49 PM To: Dmitry Nesterenko <dmitry.nesterenko@virtuozzo.com> Cc: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>; Martin Kletzander <mkletzan@redhat.com>; libvir-list@redhat.com <libvir-list@redhat.com>; Dmitry Mishin <dim@virtuozzo.com> Subject: Re: [RFC] Adding docker driver to libvirt On Thu, Apr 16, 2020 at 01:47:39PM +0000, Dmitry Nesterenko wrote:
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.
What format does the API take ? Is it a plain REST API we will call via the existing libcurl dependancy in libvirt ? 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 :|
participants (7)
-
Andrea Bolognani -
Cedric Bosdonnat -
Daniel P. Berrangé -
Dmitry Nesterenko -
Martin Kletzander -
Nikolay Shirokovskiy -
nshirokovskiy