Open Stack

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 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.
>>
>> 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 at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
>