Open Stack

> On 31 Aug 2021, at 11:50, Peng Tao <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> 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 at lists.katacontainers.io <mailto:kata-dev at lists.katacontainers.io>
>> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev <http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20210831/e952e550/attachment-0001.htm>