Open Stack

On 2021/8/31 17:52, Christophe de Dinechin wrote:
> 
> 
>> On 31 Aug 2021, at 11:50, Peng Tao <bergwolf at hyper.sh 
>> <mailto:bergwolf at 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 at gibson.dropbear.id.au 
>>>>>> <mailto: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?
> 
> 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.

I intentionally asked the second one because IMO we need a design for 
the replacement instead of just saying that we need to drop govmm ;-) I 
share the same concern that Fabiano expressed earlier:

 > "when we have time / motivation" is the part that worries me the 
most, David.

Cheers,
Tao

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