Re: Configuring migration

[Juan Quintela <quintela@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> wrote:
> 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' } }

Once that we are doing incompatible changes:
- resume can be another parameter
- detach is not needed.  QMP don't use it, and HMP don't need to pass it
  to qmp_migrate() to make the non-detached implemntation.


>      (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.

This makes sense to me, but once that we change, we could try to merge
capabilities and parameters.  See my other email on this topic.
Basically the distition is arbitrary, so just have one of them.

Or better, as I said in the other email, we have two types of
parameters:
- the ones that need to be set before migration starts
- the ones that can be changed at any time

So to be simpler, I think that 1st set should be passed to the commands
themselves and the others should only be set with
migrate_set_parameters.

Later, Juan.