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

[Daniel P . Berrangé]

On Thu, Nov 02, 2023 at 03:25:25PM +0100, Markus Armbruster wrote:
> 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.

Do we even need to do this via a QAPI object ?

Why are we not just making the obvious design change of passing everything
with the 'migrate' / 'migrate-incoming' commands that kick it off:

ie:

{ 'command': 'migrate',
  'data': {'uri': 'str',
           '*channels': [ 'MigrationChannel' ],
           '*capabilities': [ 'MigrateCapability' ],
           '*parameters': [ 'MigrateParameters' ],
           '*detach': 'bool', '*resume': 'bool' } }

     (deprecated bits trimmed for clarity)

and the counterpart:

{ 'command': 'migrate-incoming',
             'data': {'*uri': 'str',
                      '*channels': [ 'MigrationChannel' ],
                      '*capabilities': [ 'MigrateCapability' ],
                      '*parameters': [ 'MigrateParameters' ] } }

such that the design is just like 99% of other commands which take
all their parameters directly. We already have 'migrate-set-parameters'
remaining for the runtime tunables, and can deprecate the usage of this
when migration is not already running, and similarly deprecate
migrate-set-capabilities.

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