Re: Configuring migration

[Juan Quintela]

Daniel P. Berrangé <berrange@redhat.com> wrote:
> On Tue, Nov 14, 2023 at 11:28:28AM +0100, Juan Quintela wrote:
>> 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:
>
> This is not incompatible - it is fully backcompatible with existing
> usage initially, which should make it pretty trivial to introduce
> to the code. Mgmt apps can carry on using migrate-set-capabilities
> and migrate-set-parameters, and ignore these new 'capabilities'
> and 'parameters' fields if desired.
>
> Only once we decide to deprecate migrate-set-capabilities, would
> it become incompatible.

Oh, I mean that the interface is incompatible.  Not that we can't do the
current one on top of this one.

>> - resume can be another parameter
>
> Potentially yes, but 'resume' is conceptually different to all
> the other capabilities and parameters, so I could see it remaining
> as a distinct field as it is now

It is conceptually different.  But it is the _only_ one needed that
capability.  And putting that on the parameters and just checking it
first will achieve the same result.  I think that being special here
don't help, for instance, to check for incompatible things, we need to
also pass resume (it is only valid for postcopy).

>> - 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.
>
> We could deprecate that today then.

Yeap.  Will do it.

>> >      (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.
>
> As a mgmt app dev I don't want there to be an arbitrary distinction
> between what I can pass with 'migrate' and what I have to use a
> separate command for.

If it ever wants to set the parameter that it "can" change after
migration starts, it needs to know that they are different.

Once told that, I don't write management apps and you do so I am not
discussing further O:-)

> If I'm starting a migration, I just want to
> pass all the settings with the 'migrate' command. I should not have
> to care about separate 'migrate-set-parameters' command at all, unless
> I actually need to change something on the fly (many migrates will
> never need this).


What OpenStack/CNV do?

If my memory is right, at least one of them used progressive downtimes
every couple of iterations or something like that.

Later, Juan.

> With regards,
> Daniel