Re: Configuring migration (was: [PATCH v3 3/4] migration/qapi: Replace @MigrateSetParameters with @MigrationParameters)

[Peter Xu <peterx@redhat.com>]

On Thu, Nov 02, 2023 at 03:25:25PM +0100, Markus Armbruster wrote:
> Juan Quintela <quintela@redhat.com> writes:
> 
> > Markus Armbruster <armbru@redhat.com> wrote:
> >> Peter Xu <peterx@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?

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?
Migration will require each cap/parameter to be set separately anytime,
e.g., the user can adjust downtime / bandwidth even during migration in
progress.

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.

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.

Thanks,

-- 
Peter Xu