On 2021/8/31 13:21, David Gibson wrote:
On Tue, Aug 31, 2021 at 11:15:06AM +1000, David Gibson wrote:
On Mon, Aug 30, 2021 at 02:20:54PM +0200, Christophe de Dinechin wrote:
On 24 Aug 2021, at 06:34, David Gibson <kata-dev@gibson.dropbear.id.au> wrote:
So.. I just discovered I had a mail misconfiguration which meant at least one recent message I sent to the list on the govmm stuff didn't get through. Which probably explains why I had a different idea of what was going on that other people seem to have had.
I proposed the integration of govmm into the Kata repository for two reasons:
1) To avoid the back and forth of synchronized govmm & Kata changes 2) To avoid maintaining another external interface
When I first pitched it to Fabiano I had the impression that Kata was the only user of govmm making it an internal interface in practice, so (1) was the main motivation. Having discovered that's not the case, though, (2) is really the more important factor. The Kata team really doesn't have the resources to maintain a general VMM interface - which is in fact an extremely difficult problem (witness the complexity of libvirt). It's made more difficult by the fact that there's not really a natural API boundary in between qemu itself and Kata's hypervisor interface, so what is and isn't in govmm is already pretty arbitrary and based on Kata's needs.
AIUI, at the last AC meeting, the decision was made to move govmm into the kata-containers repo, encouraging external users to consume it from the new location. That addresses (1), but not (2), since it's still effectively an external interface. It makes the dilineation of that interface even less clear than it already is.
Yes and no. By putting it inside the kata repo, we make it clear that it is not a public interface. Anyone using it is at risk of breakage.
Except that that appears to be explicitly *not* the intention.
AIUI, Salvatore (representing the one known external user) was at the AC meeting, and the decision was to merge the repo but that Salavatore would consume govmm from the kata-containers repository. Salvatore's use was cited as a possible argument against my draft patch to remove some things that are not used in Kata [0].
In other words, still an external interface in practice.
I finally spotted the links to the recordings of the AC meetings, so I've watched those and have a better idea of the details that were discussed. Salvatore using govmm from within the kata repository and being kept in the loop for upcoming changes was explicitly discussed.
So, an implicit promise was essentially made to maintain this as an external interface if integrated (at least for now). But as discussed above, I really don't think we have anyone lined up to actually fulfil that promise.
It's a little vexing: the discussion started off with essentially the arguments I've made above, however, when it came to actually making a decision focus shifted to the proposed "interim step" of combining the repository but having it used externalling. My fundamental point is that as an interim step this is counter-productive:
- It makes things harder on the Kata side, because we still have to treat this as a maintained external interface that we can't break.
- It makes things harder on the external user side, because now you need to import a different (and much larger) repository, and the risk of an interface being broken from the Kata side is increased (because it's less obviously an external interface).
So to re-iterate, I really think the next step ought to be instead to *fork* govmm into the kata containers repository. Once there it becomes a burely Kata-local copy, which can be modified (and/or eliminated) as per Kata needs. As @sameo said on the call, we already have a hypervisor abstraction layer, we don't need a second one. External users keep using the external govmm, and its up to those users to fix bugs or make extensions there.
I suggested on the AC call to fork govmm because I thought we'd want to keep its abstraction. If the long term goal is to drop govmm layer, we should make a **copy** of it instead of moving it to kata repo IMO. Then as David outlined, we can tailor it and eventually replace it with a kata specific direct integration with qemu. OTOH, I think what's important for now is to reach agreements on these questions: 1. Do we want to keep the govmm abstraction layer for kata? 2. If not, what is the replacement? We can take it to today's AC meeting IMO. Cheers, Tao
_______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev