[kata-dev] govmm/Kata integration, revisited

Christophe de Dinechin cdupontd at redhat.com
Mon Aug 30 12:20:54 UTC 2021



> On 24 Aug 2021, at 06:34, David Gibson <kata-dev at 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.

What we should do, however, is mark that with a tag or branch so
that if we create incompatible changes, external users can still
return to a compatible version. Also maybe add a README pointing
out that there is no intention to keep the API stable.

> 
> So, I really think this is a bad approach.  Instead, what I believe we
> should do is leave the govmm repository as is, but orphaned, for
> external users.  They can take up maintenance of it, if they have the
> interest.  For Kata, I think we should simply fork the current govmm
> state, removing any parts we don't need, and in future make no attempt
> to keep it as anything but an internal interface tailored for Kata's
> needs.  I believe this will let us make some significant
> simplifications.
> 
> My issue and pull request (#2393 and #2395) were made with the latter
> approach in mind, and I'm presently holding off on merging until we're
> clear on how we're proceding here.
> 
> -- 
> 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
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev




More information about the kata-dev mailing list