[RFC] Moving this project into kata-containers repository
devimc opened this issue · 9 comments
Proposal
In today's (2021-08-02) Kata Containers Architecture Committee meeting we discussed the possibility of moving govmm repository (this repo) into kata-containers repository (https://github.com/kata-containers/kata-containers/tree/main/src/runtime/virtcontainers/pkg/qemu) this could simplify us a lot the things, development and bug fixing would be more agile and the integration with Kata Containers would be tested easily through Kata's CI.
Impact
Projects vendoring (importing) this project would be impacted, their go.mod files and the imports in source code must be updated, for example:
import "github.com/kata-containers/kata-containers/src/runtime/virtcontainers/pkg/qemu"Last call
If you are using this project, it's time to speak up!
Please comment in this issue or reply to this thread http://lists.katacontainers.io/pipermail/kata-dev/2021-July/002044.html
Thanks
I fully agree with the approach. I would go even further and I would not advertise the govmm API as public so it will not be used by other projects. It will reduce maintenance as we will not have public APIs and it will allow us to remove obsolete code when not needed.
We are using actively the library and the govmm API. It would not be a problem if the library will be moved to a different GH org. However, it would be a problem if as suggested by @marcel-apf the govmm API won't be public anymore.
@mazzy89, thanks for the prompt answer.
Are you using the govmm API tied to a specific version of QEMU? Would you happen to have time to join the next Architecture Committee call, which happens on Tuesdays 3pm UTC at https://zoom.us/j/91444082924?
Basically, I'd like to get the discussion going on how you rely on the library, and what kind of limitations @marcel-apf & @dgibson are facing on their side, and then get into an agreement on the way to go from there.
@mazzy89 in that case we need to limit ourselves to the proposed solution so it would allow you to continue to use the govmm project. I second @fidencio's invitation to the weekly call as I am curious to understand how are you using the project since it seems so tight coupled to what the kata project needs
@mazzy98, the basic problem here is that maintaining a general purpose VMM interface is actually an enormously complex task, which the Kata team really doesn't have the wherewithal to do. That's the underlying reason why I think we want to integrate this into Kata and allow it to become purely and unapologetically Kata specific. This will significantly reduce maintenance burden.
Nothing will stop you from continuing to use govmm as it stands, obviously, but I just don't think we have the people and energy to continue to maintain govmm as a standalone package. Already there are a heap of weird limitations in it that only make sense because of what Kata needed of it.
@devimc, I'd actually suggest a different approach here. Including the physical repo with Kata helps with some problems, but allowing other projects to reference into the Kata repository to use the package means the package is still advertising itself as a maintained general purpose interface. We simply don't have the spare resources to deliver that.
So instead, I think we should simply fork govmm into the Kata repo for our internal use only. The govmm repository would be left as is so that people can continue to use it, but would no longer be actively maintainer (unless some interested third party takes up that burden).
For the fork within Kata, I'd then expect a bunch of simplifications to follow gradually, using the fact that we're serving Kata only to reduce complexity. Eventually, I anticipate this will lead to what's now govmm being mostly dismantled. I honestly don't think there's a abstraction we can establish in between Kata's type hypervisor interface and almost the bare qemu command line and QMP that's both maintainable and valuable.
Thank you guys for providing transparently the reasons. I'd like to join the meeting next week and provide you the reasons how and why we use govmm but I totally understand your reasons. Maintaing a project requires resources. I will discuss this internally and perhaps we might take over because very interested on the govmm library.
Made an issue to track this from the fork/kata-containers side here: kata-containers/kata-containers#2393
Well, we did it: kata-containers/kata-containers#3468.