Having govmm as part of virtcontainers
Folks, David Gibson, in an internal conversation, raised Today the pain of trying to fix a QEMU + kata-containers issue, having to update govmm, get it reviewed & merged on the govmm side, and only then be able to proceed with the work on QEMU + kata-containers. I can relate to that, I'm pretty sure other developers can relate to that as well. Considering that govmm is only used by kata-containers, wouldn't it be the case to have it as part of the virt-containers package rather than it's own project that we vendor? I tend to see this as taking a step towards how we integrate cloud-hypervisor with kata-containers. What do people think about this? Is this a move we can make as part of the 2.3 release cycle? Or are there other users of govmm that we missed? Opinions, concerns, suggestions, all of those are super welcome. Best Regards, -- Fabiano Fidêncio
On 2021/7/28 15:50, Fabiano Fidêncio wrote:
Folks,
David Gibson, in an internal conversation, raised Today the pain of trying to fix a QEMU + kata-containers issue, having to update govmm, get it reviewed & merged on the govmm side, and only then be able to proceed with the work on QEMU + kata-containers. I can relate to that, I'm pretty sure other developers can relate to that as well.
Considering that govmm is only used by kata-containers, wouldn't it be the case to have it as part of the virt-containers package rather than it's own project that we vendor? This was raised before. The reason we still used a separate repo for govmm was for kata 1.x back then. Now that kata 1.x is officially EOL, I'd say we should just move govmm into virtcontainers.
I tend to see this as taking a step towards how we integrate cloud-hypervisor with kata-containers.
Could you explain a bit on how it relates to cloud-hypervisor? Right now govmm only supports qemu. Do you plan to make it a generic vmm handling layer as it should be by its name? (Which I would love to see for sure!) Cheers, Tao
What do people think about this? Is this a move we can make as part of the 2.3 release cycle? Or are there other users of govmm that we missed?
Opinions, concerns, suggestions, all of those are super welcome.
Best Regards,
On Wed, Jul 28, 2021 at 10:00 AM Peng Tao <bergwolf@hyper.sh> wrote:
On 2021/7/28 15:50, Fabiano Fidêncio wrote:
Folks,
David Gibson, in an internal conversation, raised Today the pain of trying to fix a QEMU + kata-containers issue, having to update govmm, get it reviewed & merged on the govmm side, and only then be able to proceed with the work on QEMU + kata-containers. I can relate to that, I'm pretty sure other developers can relate to that as well.
Considering that govmm is only used by kata-containers, wouldn't it be the case to have it as part of the virt-containers package rather than it's own project that we vendor? This was raised before. The reason we still used a separate repo for govmm was for kata 1.x back then. Now that kata 1.x is officially EOL, I'd say we should just move govmm into virtcontainers.
Yay!
I tend to see this as taking a step towards how we integrate cloud-hypervisor with kata-containers.
Could you explain a bit on how it relates to cloud-hypervisor? Right now govmm only supports qemu. Do you plan to make it a generic vmm handling layer as it should be by its name? (Which I would love to see for sure!)
What I meant was, nowadays the cloud-hypervisor code we deal with is under https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir..., firecracker also has its integration code as part of https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir.... With that in mind, govmm could actually be something like https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir... (which doesn't exist yet). Of course I'd like to have an abstraction that could actually handle all the VMMs, but at this point I'm not sure whether it's possible, or even worth it. But that's something to be calmly evaluated and discussed, as future steps. Did I answer your question, Tao? Best Regards, -- Fabiano Fidêncio
On Wed, Jul 28, 2021 at 10:09:21AM +0200, Fabiano Fidêncio wrote:
On Wed, Jul 28, 2021 at 10:00 AM Peng Tao <bergwolf@hyper.sh> wrote:
On 2021/7/28 15:50, Fabiano Fidêncio wrote:
Folks,
David Gibson, in an internal conversation, raised Today the pain of trying to fix a QEMU + kata-containers issue, having to update govmm, get it reviewed & merged on the govmm side, and only then be able to proceed with the work on QEMU + kata-containers. I can relate to that, I'm pretty sure other developers can relate to that as well.
Considering that govmm is only used by kata-containers, wouldn't it be the case to have it as part of the virt-containers package rather than it's own project that we vendor? This was raised before. The reason we still used a separate repo for govmm was for kata 1.x back then. Now that kata 1.x is officially EOL, I'd say we should just move govmm into virtcontainers.
Yay!
I tend to see this as taking a step towards how we integrate cloud-hypervisor with kata-containers.
Could you explain a bit on how it relates to cloud-hypervisor? Right now govmm only supports qemu. Do you plan to make it a generic vmm handling layer as it should be by its name? (Which I would love to see for sure!)
What I meant was, nowadays the cloud-hypervisor code we deal with is under https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir..., firecracker also has its integration code as part of https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir.... With that in mind, govmm could actually be something like https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir... (which doesn't exist yet).
Of course I'd like to have an abstraction that could actually handle all the VMMs, but at this point I'm not sure whether it's possible, or even worth it.
That kind of depends what you're meaning. Making a *general-purpose* abstraction layer for VMMs is an extremely difficult problem, and not something we can reasonably tackle. That's essentially what libvirt aimed to be - it's been going for decades and it's at best kinda sorta there. Making a VMM abstraction layer aimed solely at Kata's needs is much more manageable. In fact, we have one already: the 'hypervisor' interface in virtcontainers. IMO, there's not really a feasible abstraction boundary in between the hypervisor interface and the vmm itself. I think that's a significant why govmm has ended up as qemu-only and Kata-only in practice.
But that's something to be calmly evaluated and discussed, as future steps.
Did I answer your question, Tao?
Best Regards,
-- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
On 29 Jul 2021, at 06:11, David Gibson <david@gibson.dropbear.id.au> wrote:
On Wed, Jul 28, 2021 at 10:09:21AM +0200, Fabiano Fidêncio wrote:
On Wed, Jul 28, 2021 at 10:00 AM Peng Tao <bergwolf@hyper.sh> wrote:
On 2021/7/28 15:50, Fabiano Fidêncio wrote:
Folks,
David Gibson, in an internal conversation, raised Today the pain of trying to fix a QEMU + kata-containers issue, having to update govmm, get it reviewed & merged on the govmm side, and only then be able to proceed with the work on QEMU + kata-containers. I can relate to that, I'm pretty sure other developers can relate to that as well.
Considering that govmm is only used by kata-containers, wouldn't it be the case to have it as part of the virt-containers package rather than it's own project that we vendor? This was raised before. The reason we still used a separate repo for govmm was for kata 1.x back then. Now that kata 1.x is officially EOL, I'd say we should just move govmm into virtcontainers.
Yay!
I tend to see this as taking a step towards how we integrate cloud-hypervisor with kata-containers.
Could you explain a bit on how it relates to cloud-hypervisor? Right now govmm only supports qemu. Do you plan to make it a generic vmm handling layer as it should be by its name? (Which I would love to see for sure!)
What I meant was, nowadays the cloud-hypervisor code we deal with is under https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir..., firecracker also has its integration code as part of https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir.... With that in mind, govmm could actually be something like https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir... (which doesn't exist yet).
Of course I'd like to have an abstraction that could actually handle all the VMMs, but at this point I'm not sure whether it's possible, or even worth it.
That kind of depends what you're meaning. Making a *general-purpose* abstraction layer for VMMs is an extremely difficult problem, and not something we can reasonably tackle. That's essentially what libvirt aimed to be - it's been going for decades and it's at best kinda sorta there.
Hard, but fair. +1
Making a VMM abstraction layer aimed solely at Kata's needs is much more manageable. In fact, we have one already: the 'hypervisor' interface in virtcontainers.
IMO, there's not really a feasible abstraction boundary in between the hypervisor interface and the vmm itself. I think that's a significant why govmm has ended up as qemu-only and Kata-only in practice.
But that's something to be calmly evaluated and discussed, as future steps.
Did I answer your question, Tao?
Best Regards,
-- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au <http://gibson.dropbear.id.au/> | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson <http://www.ozlabs.org/~dgibson> _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io <mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev <http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev>
Folks I've opened an issue in the govmm repository. Please speak up if you consider we shouldn't move govmm into kata-containers. Thanks -- Julio [1]: https://github.com/kata-containers/govmm/issues/195 On Fri, 2021-07-30 at 17:33 +0200, Christophe de Dinechin wrote: On 29 Jul 2021, at 06:11, David Gibson <david@gibson.dropbear.id.au<mailto:david@gibson.dropbear.id.au>> wrote: On Wed, Jul 28, 2021 at 10:09:21AM +0200, Fabiano Fidêncio wrote: On Wed, Jul 28, 2021 at 10:00 AM Peng Tao <bergwolf@hyper.sh<mailto:bergwolf@hyper.sh>> wrote: On 2021/7/28 15:50, Fabiano Fidêncio wrote: Folks, David Gibson, in an internal conversation, raised Today the pain of trying to fix a QEMU + kata-containers issue, having to update govmm, get it reviewed & merged on the govmm side, and only then be able to proceed with the work on QEMU + kata-containers. I can relate to that, I'm pretty sure other developers can relate to that as well. Considering that govmm is only used by kata-containers, wouldn't it be the case to have it as part of the virt-containers package rather than it's own project that we vendor? This was raised before. The reason we still used a separate repo for govmm was for kata 1.x back then. Now that kata 1.x is officially EOL, I'd say we should just move govmm into virtcontainers. Yay! I tend to see this as taking a step towards how we integrate cloud-hypervisor with kata-containers. Could you explain a bit on how it relates to cloud-hypervisor? Right now govmm only supports qemu. Do you plan to make it a generic vmm handling layer as it should be by its name? (Which I would love to see for sure!) What I meant was, nowadays the cloud-hypervisor code we deal with is under https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir..., firecracker also has its integration code as part of https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir.... With that in mind, govmm could actually be something like https://github.com/kata-containers/kata-containers/tree/main/src/runtime/vir... (which doesn't exist yet). Of course I'd like to have an abstraction that could actually handle all the VMMs, but at this point I'm not sure whether it's possible, or even worth it. That kind of depends what you're meaning. Making a *general-purpose* abstraction layer for VMMs is an extremely difficult problem, and not something we can reasonably tackle. That's essentially what libvirt aimed to be - it's been going for decades and it's at best kinda sorta there. Hard, but fair. +1 Making a VMM abstraction layer aimed solely at Kata's needs is much more manageable. In fact, we have one already: the 'hypervisor' interface in virtcontainers. IMO, there's not really a feasible abstraction boundary in between the hypervisor interface and the vmm itself. I think that's a significant why govmm has ended up as qemu-only and Kata-only in practice. But that's something to be calmly evaluated and discussed, as future steps. Did I answer your question, Tao? Best Regards, -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au<http://gibson.dropbear.id.au/> | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list <mailto:kata-dev@lists.katacontainers.io> kata-dev@lists.katacontainers.io <http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
On Tue, Aug 03, 2021 at 03:51:03PM +0000, Montes, Julio wrote:
Folks
I've opened an issue in the govmm repository.
Please speak up if you consider we shouldn't move govmm into kata-containers.
Meanwhile, I've opened an issue[0] and a pull request[1] in the kata-containers repository with an RFC implementation of this merge (though with a slightly different emphasis to Julio's approach). [0] https://github.com/kata-containers/kata-containers/issues/2393 [1] https://github.com/kata-containers/kata-containers/pull/2395 -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
On 28 Jul 2021, at 09:50, Fabiano Fidêncio <fabiano@fidencio.org> wrote:
Folks,
David Gibson, in an internal conversation, raised Today the pain of trying to fix a QEMU + kata-containers issue, having to update govmm, get it reviewed & merged on the govmm side, and only then be able to proceed with the work on QEMU + kata-containers. I can relate to that, I'm pretty sure other developers can relate to that as well.
Considering that govmm is only used by kata-containers, wouldn't it be the case to have it as part of the virt-containers package rather than it's own project that we vendor? I tend to see this as taking a step towards how we integrate cloud-hypervisor with kata-containers.
What do people think about this? Is this a move we can make as part of the 2.3 release cycle? Or are there other users of govmm that we missed?
Even if that's the case, we can still keep some external repository in sync with the internal code, e.g. using git subtrees and exporting govmm "releases" for external consumers.
Opinions, concerns, suggestions, all of those are super welcome.
Best Regards, -- Fabiano Fidêncio
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
Hi all Moving the source into kata-containers repo and keeping the original golang package as a copy may be a good idea. Like the Kubernetes way: https://github.com/kubernetes/kubernetes/tree/master/staging#using-staged-re... It will only need external work to sync the code. 2021年7月28日(水) 16:28 Christophe de Dinechin <cdupontd@redhat.com>:
On 28 Jul 2021, at 09:50, Fabiano Fidêncio <fabiano@fidencio.org> wrote:
Folks,
David Gibson, in an internal conversation, raised Today the pain of trying to fix a QEMU + kata-containers issue, having to update govmm, get it reviewed & merged on the govmm side, and only then be able to proceed with the work on QEMU + kata-containers. I can relate to that, I'm pretty sure other developers can relate to that as well.
Considering that govmm is only used by kata-containers, wouldn't it be the case to have it as part of the virt-containers package rather than it's own project that we vendor? I tend to see this as taking a step towards how we integrate cloud-hypervisor with kata-containers.
What do people think about this? Is this a move we can make as part of the 2.3 release cycle? Or are there other users of govmm that we missed?
Even if that's the case, we can still keep some external repository in sync with the internal code, e.g. using git subtrees and exporting govmm "releases" for external consumers.
Opinions, concerns, suggestions, all of those are super welcome.
Best Regards, -- Fabiano Fidêncio
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
+ Salvatore Mazzarino +1 virtcontainers/pkg/qemu should be in sync with kata-containers/govmm repo On Wed, 2021-07-28 at 22:45 +0800, bin liu wrote: Hi all Moving the source into kata-containers repo and keeping the original golang package as a copy may be a good idea. Like the Kubernetes way: https://github.com/kubernetes/kubernetes/tree/master/staging#using-staged-re... It will only need external work to sync the code. 2021年7月28日(水) 16:28 Christophe de Dinechin <cdupontd@redhat.com<mailto:cdupontd@redhat.com>>:
On 28 Jul 2021, at 09:50, Fabiano Fidêncio <fabiano@fidencio.org<mailto:fabiano@fidencio.org>> wrote:
Folks,
David Gibson, in an internal conversation, raised Today the pain of trying to fix a QEMU + kata-containers issue, having to update govmm, get it reviewed & merged on the govmm side, and only then be able to proceed with the work on QEMU + kata-containers. I can relate to that, I'm pretty sure other developers can relate to that as well.
Considering that govmm is only used by kata-containers, wouldn't it be the case to have it as part of the virt-containers package rather than it's own project that we vendor? I tend to see this as taking a step towards how we integrate cloud-hypervisor with kata-containers.
What do people think about this? Is this a move we can make as part of the 2.3 release cycle? Or are there other users of govmm that we missed?
Even if that's the case, we can still keep some external repository in sync with the internal code, e.g. using git subtrees and exporting govmm "releases" for external consumers.
Opinions, concerns, suggestions, all of those are super welcome.
Best Regards, -- Fabiano Fidêncio
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io<mailto:kata-dev@lists.katacontainers.io> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev _______________________________________________ kata-dev mailing list <mailto:kata-dev@lists.katacontainers.io> kata-dev@lists.katacontainers.io <http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
Hi Fabiano, On Wed, Jul 28, 2021 at 10:51 AM Fabiano Fidêncio <fabiano@fidencio.org> wrote:
Folks,
David Gibson, in an internal conversation, raised Today the pain of trying to fix a QEMU + kata-containers issue, having to update govmm, get it reviewed & merged on the govmm side, and only then be able to proceed with the work on QEMU + kata-containers. I can relate to that, I'm pretty sure other developers can relate to that as well.
Considering that govmm is only used by kata-containers, wouldn't it be the case to have it as part of the virt-containers package rather than it's own project that we vendor? I tend to see this as taking a step towards how we integrate cloud-hypervisor with kata-containers.
What do people think about this? Is this a move we can make as part of the 2.3 release cycle? Or are there other users of govmm that we missed?
Opinions, concerns, suggestions, all of those are super welcome.
We could keep the govmm project around, however I am trying to find the purpose. If there are no other govmm users or is not one of the KATA project deliverables, why the extra work? What is the added value of keeping govmm as an external repository? I had a look, I even wrote a simple patch, it looks like a collection of "internal" APIs needed by KATA. I would simply integrate it. Thanks, Marcel
Best Regards, -- Fabiano Fidêncio
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
participants (8)
-
bin liu
-
Christophe de Dinechin
-
David Gibson
-
david＠gibson.dropbear.id.au
-
Fabiano Fidêncio
-
Marcel Apfelbaum
-
Montes, Julio
-
Peng Tao