(In reply to Luca Miccini from comment #0)
> Fix is apparently ready to merge since Sep 2017:
> 
> "Rework server migrate to support live and no-live"
> https://review.openstack.org/#/c/460059/
>
> Is there anything we can do to speed things up?

Moving to DFG:Compute so domain experts can take a look at the patches as well.

(In reply to Luca Miccini from comment #0)
> Description of problem:
> 
> This BZ has been opened to track the progress of:
> 
> https://bugs.launchpad.net/python-openstackclient/+bug/1411190
> 
> ~~~
> Nova live-migration semantics says that you can migrate server on host
> chosen by scheduled if host didn't specified.
> 
> usage: nova live-migration [--block-migrate] [--disk-over-commit]
>                            <server> [<host>]
> 
> openstack server migrate didn't provide that opinion, even you call it with
> empty argument (--live '')
> usage: server migrate [-h] [--live <hostname>]
>                       [--shared-migration | --block-migration]
>                       [--disk-overcommit | --no-disk-overcommit] [--wait]
>                       <server>
> 
> Also there is a confusion with --shared-migration and --block-migration:
> block migration in fact disables it.
> ~~~
> 
> Fix is apparently ready to merge since Sep 2017:
> 
> "Rework server migrate to support live and no-live"
> https://review.openstack.org/#/c/460059/
> 
> Is there anything we can do to speed things up?

Yeah this isn't ready to merge and IMHO shouldn't, the suggested options are pretty awful.

AFAICT this is just a bug with openstackclient's arg handling :

https://github.com/openstack/python-openstackclient/blob/30b2203dc75a4fc776875b02258f8d54660249d7/openstackclient/compute/v2/server.py#-L1318-L1322

IMHO --live should default to None, this should then be passed on to the n-api call resulting in n-schd picking the host by default as outlined in our API docs here :

https://developer.openstack.org/api-ref/compute/#live-migrate-server-os-migratelive-action

Julie, I think DFG:UI own python-openstackclient so I'm going to throw this back over for now and remove RFE from the title. Please let me know if there are any additional questions for the compute DFG here.

(In reply to Lee Yarwood from comment #2)
> (In reply to Luca Miccini from comment #0)
> > Description of problem:
> > 
> > This BZ has been opened to track the progress of:
> > 
> > https://bugs.launchpad.net/python-openstackclient/+bug/1411190
> > 
> > ~~~
> > Nova live-migration semantics says that you can migrate server on host
> > chosen by scheduled if host didn't specified.
> > 
> > usage: nova live-migration [--block-migrate] [--disk-over-commit]
> >                            <server> [<host>]
> > 
> > openstack server migrate didn't provide that opinion, even you call it with
> > empty argument (--live '')
> > usage: server migrate [-h] [--live <hostname>]
> >                       [--shared-migration | --block-migration]
> >                       [--disk-overcommit | --no-disk-overcommit] [--wait]
> >                       <server>
> > 
> > Also there is a confusion with --shared-migration and --block-migration:
> > block migration in fact disables it.
> > ~~~
> > 
> > Fix is apparently ready to merge since Sep 2017:
> > 
> > "Rework server migrate to support live and no-live"
> > https://review.openstack.org/#/c/460059/
> > 
> > Is there anything we can do to speed things up?
> 
> Yeah this isn't ready to merge and IMHO shouldn't, the suggested options are
> pretty awful.
> 
> AFAICT this is just a bug with openstackclient's arg handling :
> 
> https://github.com/openstack/python-openstackclient/blob/
> 30b2203dc75a4fc776875b02258f8d54660249d7/openstackclient/compute/v2/server.
> py#-L1318-L1322
> 
> IMHO --live should default to None, this should then be passed on to the
> n-api call resulting in n-schd picking the host by default as outlined in
> our API docs here :
> 
> https://developer.openstack.org/api-ref/compute/#live-migrate-server-os-
> migratelive-action
> 
> Julie, I think DFG:UI own python-openstackclient so I'm going to throw this
> back over for now and remove RFE from the title. Please let me know if there
> are any additional questions for the compute DFG here.

Agreed, I pointed to that upstream review as it looked like this was intended behavior. If we can reconcile the two clients without adding additional complexity that's even better :)

> Also there is a confusion with --shared-migration and --block-migration:
> block migration in fact disables it.

Just noticed this bit in the original bug description also - fwiw that should be resolved as part of bug 1424129.

how about something like:

        parser.add_argument(
            '--live',
            metavar='<hostname>',
            nargs='?',
            const=None,
            default=False,
            help=_('Target hostname (default=None)'),
        )

...

        if parsed_args.live or parsed_args.live == None:
            server.live_migrate(
                host=parsed_args.live,
                block_migration=parsed_args.block_migration,
                disk_over_commit=parsed_args.disk_overcommit,
            )



test cases:

1. user does not pass "--live" at all

result:  parsed_args.live = False

2. user passes "--live" but no hostname

result: parsed_args.live == None, live migration is triggered with empty destination so n.scheduler picks a suitable compute

3. user passes "--live" with <hostname>

result: parsed_args.live == <hostname>, live migration with explicit destination.


Seems to be working fine in my lab.

Updated version of the patch posted that _shouldn't_ be hit by nasty argparse issues (though it's nasty in its own way)

This is merged now. Because it adds a new flag and deprecates an existing one, I don't think it's possible to backport this. Moved to POST as this should get imported as part of the OSP16 release.

[root@controller-0 heat-admin]# podman exec -it keystone sh -c "rpm -qa | grep openstack-keystone"
openstack-keystone-16.0.1-0.20191030053432.d5f9c68.el8ost.noarch
[root@compute-0 heat-admin]# podman exec -it nova_compute sh -c "rpm -qa | grep openstack-nova"
openstack-nova-common-20.0.2-0.20191122201703.56a43b8.el8ost.noarch
openstack-nova-compute-20.0.2-0.20191122201703.56a43b8.el8ost.noarch
openstack-nova-migration-20.0.2-0.20191122201703.56a43b8.el8ost.noarch
[root@compute-0 heat-admin]# podman exec -it nova_compute sh -c "rpm -qa | grep puppet-nova"
puppet-nova-15.4.1-0.20191126042922.b1bb388.el8ost.noarch
[root@compute-0 heat-admin]# podman exec -it nova_compute sh -c "rpm -qa | grep python3-nova"
python3-novaclient-15.1.0-0.20190919143437.cd396b8.el8ost.noarch
python3-nova-20.0.2-0.20191122201703.56a43b8.el8ost.noarch

############################
# Live-migrate without Host
############################
(overcloud) [stack@undercloud-0 ~]$ openstack server list --long -f value -c Name -f value -c 'Status' -f value -c Host
test-vm ACTIVE compute-0.redhat.local
(overcloud) [stack@undercloud-0 ~]$ openstack server migrate --live-migration --block-migration test-vm
(overcloud) [stack@undercloud-0 ~]$ openstack server list --long -f value -c Name -f value -c 'Status' -f value -c Host
test-vm MIGRATING compute-0.redhat.local
(overcloud) [stack@undercloud-0 ~]$ openstack server list --long -f value -c Name -f value -c 'Status' -f value -c Host
test-vm ACTIVE compute-1.redhat.local

############################
# Live-migrate with Host
############################
(overcloud) [stack@undercloud-0 ~]$ openstack server migrate --live-migration --block-migration --host compute-0.redhat.local test-vm
(overcloud) [stack@undercloud-0 ~]$ openstack server list --long -f value -c Name -f value -c 'Status' -f value -c Host
test-vm MIGRATING compute-1.redhat.local
(overcloud) [stack@undercloud-0 ~]$ openstack server list --long -f value -c Name -f value -c 'Status' -f value -c Host
test-vm ACTIVE compute-0.redhat.local

#############################
# Use --live instead
#############################
(overcloud) [stack@undercloud-0 ~]$ openstack server list --long -f value -c Name -f value -c 'Status' -f value -c Host
test-vm ACTIVE compute-0.redhat.local
(overcloud)(overcloud) [stack@undercloud-0 ~]$ openstack server migrate --live compute-1.redhat.local --block-migration test-vm
The --live option has been deprecated. Please use the --live-migration option instead.
(overcloud) [stack@undercloud-0 ~]$ openstack server list --long -f value -c Name -f value -c 'Status' -f value -c Host
test-vm ACTIVE compute-1.redhat.local

#####################################################
# Attempt to live migrate with --live and --host
#####################################################
(overcloud) [stack@undercloud-0 ~]$ openstack server migrate --live-migration --host compute-1.redhat.local --live compute-0.redhat.local --block-migration test-vm
usage: openstack server migrate [-h] [--live-migration]
                                [--live <hostname> | --host <hostname>]
                                [--shared-migration | --block-migration]
                                [--disk-overcommit | --no-disk-overcommit]
                                [--wait]
                                <server>
openstack server migrate: error: argument --live: not allowed with argument --host

###########################################################
# Use --live and --live-migration at the same time
###########################################################
(overcloud) [stack@undercloud-0 ~]$ openstack server list --long -f value -c Name -f value -c 'Status' -f value -c Host
test-vm ACTIVE compute-1.redhat.local
(overcloud) [stack@undercloud-0 ~]$ openstack server migrate --live-migration --live compute-1.redhat.local --block-migration test-vm
The --live option has been deprecated. Please use the --live-migration option instead.
(overcloud) [stack@undercloud-0 ~]$ openstack server list --long -f value -c Name -f value -c 'Status' -f value -c Host
test-vm MIGRATING compute-1.redhat.local
(overcloud) [stack@undercloud-0 ~]$ openstack server list --long -f value -c Name -f value -c 'Status' -f value -c Host
test-vm ACTIVE compute-0.redhat.local

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2020:0283