Re: Redesign of QEMU startup & initial configuration

[Mark Burton]

> 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. 

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”….

Is the argument about whether we re-implement the existing CLI ontop of the 
‘low level’ API (aka QAPI)?

> 
> 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?

> 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.

Cheers
Mark.

> 
> 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 :|
>