[RFC] Moving this project into kata-containers repository about govmm HOT 9 CLOSED

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.

from govmm.

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.

from govmm.

@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.

from govmm.

@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 😀.

from govmm.

@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.

from govmm.

@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.

from govmm.

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.

from govmm.

Made an issue to track this from the fork/kata-containers side here: kata-containers/kata-containers#2393

from govmm.

Well, we did it: kata-containers/kata-containers#3468.

from govmm.