[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Redesign of QEMU startup & initial configuration
From: |
Mark Burton |
Subject: |
Re: Redesign of QEMU startup & initial configuration |
Date: |
Tue, 14 Dec 2021 15:42:52 +0100 |
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 :|
>
- Re: Redesign of QEMU startup & initial configuration, (continued)
- Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/10
- Re: Redesign of QEMU startup & initial configuration, Markus Armbruster, 2021/12/13
- Re: Redesign of QEMU startup & initial configuration, Paolo Bonzini, 2021/12/13
- Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/13
- Re: Redesign of QEMU startup & initial configuration, Mark Burton, 2021/12/13
- Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/14
- Re: Redesign of QEMU startup & initial configuration, Mark Burton, 2021/12/14
- Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/14
- Re: Redesign of QEMU startup & initial configuration, Mark Burton, 2021/12/14
- Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/14
- Re: Redesign of QEMU startup & initial configuration,
Mark Burton <=
- Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/14
- Re: Redesign of QEMU startup & initial configuration, Markus Armbruster, 2021/12/14
- Re: Redesign of QEMU startup & initial configuration, Mark Burton, 2021/12/14
Re: Redesign of QEMU startup & initial configuration, Markus Armbruster, 2021/12/10
- Re: Redesign of QEMU startup & initial configuration, Paolo Bonzini, 2021/12/10
- Re: Redesign of QEMU startup & initial configuration, Markus Armbruster, 2021/12/13
- Re: Redesign of QEMU startup & initial configuration, Paolo Bonzini, 2021/12/13
- Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/13
- Re: Redesign of QEMU startup & initial configuration, Paolo Bonzini, 2021/12/13
- Re: Redesign of QEMU startup & initial configuration, Daniel P . Berrangé, 2021/12/13