[kata-dev] govmm/Kata integration, revisited

Fabiano Fidêncio fidencio at redhat.com
Mon Aug 30 11:24:20 UTC 2021


David,

On Tue, Aug 24, 2021 at 6:35 AM 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.
>
> 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.

Ok, thanks.

My personal suggestion then would be:
1. Do not import govmm inside kata-containers, at all.
2. Write a thin layer with what you want to have from scratch.
3. Propose that.
4. Be cool if that's not accepted.

I don't see this as a high priority effort, though, and I think that
for the time being we could keep using govmm, as that has not been a
blocker so far.

Opinions from others?

Best Regards,
-- 
Fabiano Fidêncio




More information about the kata-dev mailing list