Daniel P. Berrangé <berra...@redhat.com> writes:
> 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 ?
No. It's merely one way to skin the cat.
> 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.
We still need commands to adjust configuration while migration runs.
