Re: Redesign of QEMU startup & initial configuration

[Daniel P . Berrangé]

On Mon, Dec 13, 2021 at 06:30:45PM +0100, Paolo Bonzini wrote:
> On 12/13/21 16:19, Markus Armbruster wrote:
> > I think it's more often just three: the long one that can do everything,
> > the short one that can do simple things (and doesn't tell you anything
> > about the long one), and the bad one you shouldn't use.
> > 
> > > If we're going to have a good CLI, it would ideally only have
> > > one way to do each given task.
> > Ideally, the long one plus good defaults suffices.
> 
> That's hard to do, because the short one typically creates both a backend
> and a frontend.  It should be possible to macro-expand into the long one + a
> -machine property, but that's extremely tedious work.

I don't think it has to be hard, we just need to approach the
problem differently to how we've done in the past.

As a general point, I think we should probably change our terminology
here. IMHO using "long" and "short" options leads to the idea that
they are alternatives that are both supported directly by the same
binary and users switch between them depending on what they need.
That's true with current QEMU impl, but I don't think we should go
down that same route again, as it is not at all user friendly and
leads to confusing docs due to multiple ways todo the same thing.

I'd call them low-level and high-level config, to make it clearer
that they're operating at different conceptual levels, and potentially
(ideally even) separate binaries.

I'd like a situation where machines always use low level config
and humans can *always* use the high level config. This implies
the high level config needs to cope with everything that the
low level config can. This might sound contradictory but it is
possible, if the user has ability to customize the mapping.


If we assume the low-level config is the QAPI based JSON, then a
high level config is essentially just a mapping of some strings
into JSON. Looking at it in this light, we can then consider the
high level config problem to simply be a JSON templating problem
and pick an off the shelf solution for that such as Jinja. 


To create our so called "short option" high level API we need to
be able to ship a collection of useful JSON config snippets, and
have a tool which reads some CLI args using them as input variables
to something like the Jinja templating engine, and then launching
the low level QEMU using the template output.


The benefit of using a general purpose JSON templating system in a
separate binary is that we no longer have to solve everything
ourselves. We can provide templates that handle some obvious common
cases. If they don't do quite what a user needs, then they can just
clone our template, tweak it, and carry on using the high level
tool.

IOW, the ability to customize the templates, means that when
launching QEMU the user only ever needs to use the high level
config on the CLI, and yet they still have ability to express
every possible QEMU config. THis is quite a different and better
experiance than today where if a short option doesn't do what
you need, you have to stop using it and pick a completely
different low level config instead.

It also means we can ship a variety of templates with mutually
exclusive defaults eg a template targetting a 1990's machine
defaults, a template targetting defaults for a general purpose
maximum portability VM, and a template targetting defaults
for virtio.

Since it would be separate from the low level QEMU, we can
also decide to use a non-C language for the high level tool.
eg write it in python if we want to use Jinja as templating,
which would also open it up as an interesting thing for a
new set of contributors who would not touch C code.

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