Cc: Paolo for QOM expertise.
Peter Xu <pet...@redhat.com> writes:
> On Thu, Nov 02, 2023 at 03:25:25PM +0100, Markus Armbruster wrote:
[...]
>> 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?
>
> Sounds doable to me.
>
> I'm not familiar with BlockdevOptions, it looks like something setup once
> and for all for all relevant parameters need to be set in the same request?
Yes, but you can "reopen", which replaces the entire configuration.
blockdev-add creates a new block backend device, and blockdev-reopen
reopens a set of existing ones. Both take the same arguments for each
device.
> Migration will require each cap/parameter to be set separately anytime,
> e.g., the user can adjust downtime / bandwidth even during migration in
> progress.
"Replace entire configuration" isn't a good fit then, because users
would have to repeat the entire configuration just to tweak one thing.
> Making all caps/parameters QOM objects, or one object containing both
> attributes, sounds like a good fit. object_property_* APIs allows setters,
> I think that's good enough for migration to trigger whatever needed (e.g.
> migration_rate_set() updates after bandwidth modifications).
>
> We can convert e.g. qmp set parameters into a loop of setting each
> property, it'll be slightly slower because we'll need to do sanity check
> for each property after each change, but that shouldn't be a hot path
> anyway so seems fine.
I figure doing initial configuration in one command is convenient. The
obvious existing command for that is object-add.
The obvious interface for modifying configuration is a command to change
just one parameter. The obvious existing command for that is qom-set.
Problem: qom-set is a death trap in general. It can modify any QOM
property with a setter, and we test basically none of them. Using it
for modifying migration configuration would signal it's okay to use
elsewhere, too. I'm not sure we want to send that message. Maybe we
want to do the opposite, and make it an unstable interface.
Aside: I believe the root problem is our failure to tie "can write" to
the object's state. Just because a property can be set with object-add
doesn't mean it can be validly changed at any time during the object's
life.
Problem: when several parameters together have to satisfy constraints,
going from one valid configuration to another valid configuration may
require changing several parameters at once, or else go through invalid
intermediate configurations.
This problem is not at all specific to the migration object.
One solution is careful design to ensure that there's always a sequence
of transitions through valid configuration. Can become complicated as
configuration evolves. Possible even impractical or impossible.
Another solution is a command to modify multiple parameters together,
leaving alone the others (unlike blockdev-reopen, which overwrites all
of them).
> It'l still be a pity that we still cannot reduce the triplications of qapi
> docs immediately even with that. But with that, it seems doable if we will
> obsolete QMP migrate-set-parameters after we can do QOM-set.
Yes.
