Open Stack

> On 31 Aug 2021, at 12:31, David Gibson <kata-dev at gibson.dropbear.id.au> wrote:
> 
> On Tue, Aug 31, 2021 at 09:23:04AM +0200, Fabiano Fidêncio wrote:
>> On Tue, Aug 31, 2021 at 5:16 AM David Gibson
>> <kata-dev at gibson.dropbear.id.au> wrote:
>>> 
>>> On Mon, Aug 30, 2021 at 01:24:20PM +0200, Fabiano Fidêncio wrote:
>>>> 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.
>>> 
>>> This really seems like making things more difficult for no benefit.
>>> govmm isn't pretty but it works now.  By forking and integrating we
>>> can strip away the unnecessary bits and clean things up as and when we
>>> have time / motivation.
>> 
>> "when we have time / motivation" is the part that worries me the most, David.
> 
> That's not an unreasonable concern.  But what's really that bad about
> having a half converted thing sitting in there for a while, as long as
> it's better than what we have now?
> 
> In addition, there's a natural motivation to fix things further in the
> integrated govmm code.  Basically every time we need to extend or fix
> something in the ex-govmm code it's an opportunity to clean up that
> code path.
> 
>>> By insisting we create a new layer upfront we
>>> force doing this as a big, difficult and disruptive mega-patch.
>> 
>> Actually, the opposite.
>> We force this to be as small and surgical as possible, because we're
>> only including the parts that actually matter for us.
> 
> So, at least at a coarse level, we do actually use most of govmm.
> It's not that govmm doesn't have code that's useful and/or neccessary
> - it's just that there's no particular rationale for what sits on the
> govmm side and what sits on the kata side.  I already made a
> first-pass removal patch, which you've seen, and it's only able to
> remove one or two functions and structures
> 
> More stuff can be removed is at a finer-grained level.  Options from
> device configs that Kata doesn't need is the obvious one.  Further on
> it's probably reasonable to start removing the govmm specific device
> representations entirely, in favour of a more general properties map,
> for example.  There doesn't seem to be much benefit to having an extra
> data structure as an intermediate between the Kata structures and
> qemu's representation.
> 
>> Then we will have an one not small patch removing the govmm vendor.
> 
> So, I'd be happy enough with this approach if we could incrementally
> introduce the new interface then drop govmm once the new interface
> covers everything.
> 
> Unfortunately, that doesn't really work, because govmm owns the qmp
> interface and the qemu command line, so we can't build a new interface
> "bottom up".

While we are at it, should we rename "govmm" to something that indicates
it's really specific to qemu? Or do we want to take the opposite route
(which was evoked yesterday) to move to VMM the "hypervisor" abstraction
that we have in Kata?

> 
> -- 
> David Gibson			| I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au <http://gibson.dropbear.id.au/>	| minimalist, thank you.  NOT _the_ _other_
> 				| _way_ _around_!
> http://www.ozlabs.org/~dgibson <http://www.ozlabs.org/~dgibson>
> _______________________________________________
> 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/20210901/314f8bbd/attachment-0001.htm>