On Tue, Nov 14, 2023 at 11:42:27AM +0100, Juan Quintela wrote:
> Daniel P. Berrangé <berra...@redhat.com> wrote:
> > On Tue, Nov 14, 2023 at 11:28:28AM +0100, Juan Quintela wrote:
> >> Daniel P. Berrangé <berra...@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.
If they're using pre-copy, yes, they both can do progressive tuning.
If using post-copy though, you potentially never need to change any
tunable on the fly.
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 :|
