Juan Quintela <quint...@redhat.com> writes:
> Markus Armbruster <arm...@redhat.com> wrote:
>> Peter Xu <pet...@redhat.com> writes:
>>
>>> On Wed, Oct 11, 2023 at 04:21:02PM +0200, Markus Armbruster wrote:
>
>>> IIRC both of them used to be the goals: either allow compat properties for
>>> old machine types, or specify migration parameters in cmdline for easier
>>> debugging and tests. I use "-global" in mostly every migration test script
>>> after it's introduced.
>>
>> You use -global just because it's easier than using monitor commands,
>> correct?
>
> It is long history. But to make things easier I will try to resume.
> In the beggining there was no "defer" method, so it was imposible to
> setup migration-channels and that kind of information.
> So we created that -global migration properties.
>
> Time pass, and we need to fix that for real, because more and more
> migration parameters need to be set bofer we start incoming migration.
> So we create migration "defer" method. And now we can set things from
> the command line/QMP.
>
> But when one is testing (i.e. migration developers), using the global
> property is much easier.
>
> I am always tempted to modify the monitor command line to allow "read
> the commands from this file at startup".
>
>> Configuration is almost entirely special (own QMP commands for
>> everything), with a little abuse of general infrastructure stirred in
>> (-global, compat props). Having capabilities in addition to parameters
>> is a useless complication. Too many features of questionable utility
>> with way too many configuration knobs.
>
> I also remember that one.
> In the beggining all migration options were bools. So we have named
> capabilities. At some point we needed parameters that were not bools,
> so we had to get the parameters thing because all the migration code
> supposed that the capabilities were bool.
>
> No, I am not defending the choices we made at the time, but that is how
> it happened.
Decisions that make sense at the time can stop making sense later.
> To be fair, when I have a new "bool" to add to migration,
> I am never sure if I have to add it as a capability or as a parameter
> that returns bool.
I'd be unsure, too.
Migration has its own idiosyncratic configuration interface, even though
its configuration needs are not special at all. This is due to a long
history of decisions that made sense at the time.
What kind of interface would we choose if we could start over now?
Let's have a look at what I consider the two most complex piece of
configuration to date, namely block backends and QOM objects.
In both cases, configuration is a QAPI object type: BlockdevOptions and
ObjectOptions.
The common members are the configuration common to all block backends /
objects. One of them is the type of block backend ("driver" in block
parlance) or QOM object ("qom-type").
A type's variant members are the configuration specific to that type.
This is suitably expressive.
We create a state object for a given configuration object with
blockdev-add / object-add.
For block devices, we even have a way to modify a state object's
configuration: blockdev-reopen. For QOM objects, there's qom-set, but I
don't expect that to work in the general case. Where "not work" can
range from "does nothing" to "explodes".
Now let's try to apply this to migration.
As long as we can have just one migration, we need just one QAPI object
to configure it.
We could create the object with -object / object_add. For convenience,
we'd probably want to create one with default configuration
automatically on demand.
We could use qom-set to change configuration. If we're not comfortable
with using qom-set for production, we could do something like
blockdev-reopen instead.
Could we move towards such a design? Turn the existing ad hoc interface
into compatibility sugar for it?
