On 31 Aug 2021, at 11:50, Peng Tao <bergwolf@hyper.sh> wrote:



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?

I think one of the points David and others have made is that we already have a hypervisor abstraction in Kata, so we don't need a second one, and that govmm is not a particularly good one either.

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