Re: Redesign of QEMU startup & initial configuration

[Daniel P . Berrangé]

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