Re: Configuring migration

["Daniel P. Berrangé" <berrange@redhat.com>]

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.

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

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

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

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