Re: KVM call for agenda for 2020-10-06

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Wed, Oct 07, 2020 at 07:50:20PM +0200, Paolo Bonzini wrote:
>> On 06/10/20 20:21, Stefan Hajnoczi wrote:
>> >     * Does command-line order matter?
>> >         * Two options: allow any order OR left-to-right ordering
>> >         * Andrea Bolognani: Most users expect left-to-right ordering,
>> > why allow any order?
>> >         * Eduardo Habkost: Can we enforce left-to-right ordering or do
>> > we need to follow the deprecation process?
>> >         * Daniel Berrange: Solve compability by introducing new
>> > binaries without the burden of backwards compability
>> 
>> I think "new binaries" shouldn't even have a command line; all
>> configuration should happen through QMP commands.  Those are naturally
>> time-ordered, which is equivalent to left-to-right, and therefore the
>> question is sidestepped.  Perhaps even having a command line in
>> qemu-storage-daemon was a mistake.
>
> Non-interactive configuration is a nice property for simpler integration
> use cases. eg launching from the shell is tedious with QMP compared to
> CLI args.

Yes.

CLI, config file and QMP are differently convenient for different use
cases.

When you want to tweak just a few things for a single run, or a few in a
row, nothing beats the CLI.

A bespoke, long-lived configuration you really want to keep in a file.

When you use a program to run QEMU, and that program does QMP anyway,
doing *everything* in QMP can be just what you want.

If we could afford just one of the three, we'd probably want to pick
QMP, because it's the most flexible (it's supports queries naturally),
and because picking something else can't eliminate QMP.  Fortunately, we
don't have to pick just one if we base on initial configuration on QAPI.

A QMP command is "send an instance of a QAPI type to QEMU, get an
instance of a QAPI type or an error back".

A CLI option or configuration file entry is the same with the return
type constrained to "nothing".

The hard part is designing the QAPI type and putting it to use in QEMU.
Wrapping it in a QMP command is utterly trivial.

Wrapping it in a CLI option is no harder (we've done it a few times).
Right now, it takes some boilerplate.  We can eliminate the boilerplate
the exact same way we did for QMP commands: generate it.

Wrapping a bunch of QAPI types in a configuration file format is a bit
more work, mostly because the bikeshed will need a coat of paint.

> This could be addressed though by having a configuration file to load
> config from, where the config entries can be mapped 1-1 onto QMP commands,
> essentially making the config file a non-interactive QMP.
>
>> The big question to me is whether the configuration should be
>> QAPI-based, that is based on QAPI structs, or QMP-based.  If the latter,
>> "object-add" (and to a lesser extent "device-add") are fine mechanisms
>> for configuration.  There is still need for better QOM introspection,
>> but it would be much simpler than doing QOM object creation via QAPI
>> struct, if at all possible.

object-add and device-add are the last two genuine users of 'gen': false
(query-qmp-schema does it out of laziness, and my "Configurable policy
for handling deprecated interfaces" series makes it stop).

I'd like to take a serious swing at QAPIfying them, with a loose schema.
Good enough for QAPI-based initial configuration interfaces.  Not good
enough for introspection, but a better QOM introspection could fill that
gap.