Re: Redesign of QEMU startup & initial configuration

[Mark Burton]

I think we’re talking at cross purposes, and probably we agree (not sure). I’ll 
top quote to try and explain my point of view.

I think there are two discussions being mixed:
1/ A discussion about improving the CLI. (Having a new one, etc etc)
2/ A discussion about supporting a low level, and complete, API that can be 
used by “management layers” (QAPI).

I think this also gets mixed up with the discussion on migrating the CLI to use 
the low level API.

I want to focus on the low level API. 

I dont see why we’re discussing a ‘high level’ thing when, for now, we have to 
support the CLI, and we have work to do on QAPI. 

If somebody wants to build a new CLI, with a new ‘high level’ interface, using 
QAPI - let them!

Cheers
Mark.



> On 14 Dec 2021, at 14:48, Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> On Tue, Dec 14, 2021 at 02:36:26PM +0100, Mark Burton wrote:
>> 
>> 
>>> On 14 Dec 2021, at 14:21, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>> 
>>> On Tue, Dec 14, 2021 at 02:11:11PM +0100, Mark Burton wrote:
>>>> 
>>>> 
>>>>> On 14 Dec 2021, at 14:05, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>>>> 
>>>>> On Mon, Dec 13, 2021 at 09:22:14PM +0100, Mark Burton wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 13 Dec 2021, at 18:59, Daniel P. Berrangé <berrange@redhat.com> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> …. we no longer have to solve everything
>>>>>>> Ourselves. 
>>>>>> 
>>>>>> I support this sentiment.
>>>>>> 
>>>>>> Lets re-factor the code so people can build what they need using an API.
>>>>>> Actually, ‘QEMU’ only need support the existing CLI, and provide a 
>>>>>> suitable internal API.
>>>>>> If that API was relatively stable, that would help those (few) who 
>>>>>> maintain a different startup mechanism (but its only a ’nice to have’). 
>>>>>> (Making that convenient, as Paolo has show, would also be ’nice to 
>>>>>> have’).
>>>>> 
>>>>> To be clear I do strongly believe that the QEMU project needs
>>>>> to deliver the higher level simplified interface too. I just
>>>>> want that higher level interface to be flexible enough to
>>>>> let end users expand on what it offers, without having to
>>>>> write C code nor having to switch entirely to the low level
>>>>> interface like we do today.
>>>>> 
>>>>> IOW, QEMU needs to deliver more than just a low level building
>>>>> block API.
>>>> 
>>>> Why?
>>>> Clearly it would be nice if “higher level” interfaceS existed in
>>>> the world. Clearly QEMU could provide one, two, or many. But, why
>>>> do you think QEMU ‘must’ provide them?
>>> 
>>> To serve our users who are not all wanting to be use a management
>>> layer. They want to be using a simple binary to spin up adhoc
>>> VMs. This is the reason why we've kept most of the short option
>>> CLI args in the existing QEMU binaries, despite having more
>>> comprehensive low level replacement args. 
>> 
>> So - there are
>> a) uses today that use the CLI as it exists.
>> b) users who might prefer a better interface if that was made available - 
>> but, again, that doesn’t require QEMU itself to do anything. If we provide a 
>> low-level API, and somebody else (you for instance) provides a ’nice’ 
>> ‘friendly’ CLI or config file reader - those users would be happy.
>> 
>> I still dont see why QEMU itself needs to provide this ‘high level’ thing.
> 
> The QEMU project has provided this high level CLI itself historically.
> In previous discussions about dropping the simplified options, leaving
> only the QAPI based options, that idea has always been rejected by a
> non-trivial number of QEMU maintainers who consider it a core part of
> our deliverable as a project.
> 
>> 
>> I think we all agree (correct me if I’m wrong) :
>> * We all want a low level interface
>> * We all want the current CLI to be supported (at least for now, though it 
>> could change in time)
>> * We all want the CLI to be based on the low level interface
>> 
>> I’m just asking why we ALSO want to support “yet another high level 
>> interface”….
> 
> You're arguing for a significant change in the scope of what QEMU
> delivers to its users, punting a bunch of functionality to be
> someone else's problem.
> 
> 
>>> If we just declare we're not going to provide this simple binary
>>> any more, then we're just casting these users adrift. This in
>> 
>> “Any more” - Are you talking about the existing CLI users?
> 
> Yes.
> 
>>> effect means they'll just carry on existing the historical QEMU
>>> binaries and we'll never be able to eliminate them, so we'll be
>>> maintaining two things forever.
>> 
>> A CLI and the low level interface? - Yes? Can we remove the CLI
>> and only support the low-level interface ? But here you seem to
>> be arguing against yourself, so I guess I misunderstood.
> 
> The current qemu-system-$TARGET emulators have a variety of
> CLI args, some low level QAPI driven, and some higher level
> simplified args. Mgmt app consumers tend to use the former,
> while our humans userbase tends to use the latter.  I'm
> saying we need to carry on serving both userbases, unless
> we get the QEMU maintainers in general to agree to a pretty
> significant change in what the project delivers. Based on
> previous discussions, I'm doubtful we'll get agreement to
> do that.
> 
> So if we're going to successfully introduce replacement
> for qemu-system-$TARGET, we need to cater for both userbases,
> albeit we can do so with separate binaries, rather than trying
> to cram low level and high level into the same.
> 
> 
> Regards,
> Daniel
> -- 
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
>