live_migration_uri should be dependant on virt_type

[Alvaro Lopez]

The "live_migration_uri" default should be dependent on the "virt_type" flag (this is the same behavior as "connection_uri").

[Solly Ross (sross-7)]

Currently, it is specified as a configuration option, since different hypervisors require different support different remote connection protocols. This would most likely be better filed as a blueprint.

[Alvaro Lopez (aloga)]

Sorry, but I do not think this is Invalid.

The "live_migration_uri" value is dependent on the libvirt type being used, and therefore, the default values should be dependent on that.

If I as an operator set libivrt_type to whatever I expect that I do not have to tweak the default values for that connection type (for example the connection url, the migration url, etc). With the current situation I will get a broken deployment where I have to figure out that live migration does not work, just because the default migration_url only works with one type of libvirt connection type.

[Sean Dague (sdague)]

Would be a good usability enhancements.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/175780

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/175780
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=3159c8fd5bea80c820e58bd38d96f5f8fe8f4503
Submitter: Jenkins
Branch: master

commit 3159c8fd5bea80c820e58bd38d96f5f8fe8f4503
Author: Alvaro Lopez Garcia <email address hidden>
Date: Tue Apr 21 10:39:30 2015 +0200

    libvirt: make live_migration_uri flag dependent on virt_type

    The default value for the "live_migration_uri" flag should be
    dependent on the "virt_type" flag, as the "connection_uri" flag is. This
    way, an operator can set the "virt_type" flag without the need to check
    for each individual uri.

    DocImpact: Changed the default value of the "live_migration_uri" flag,
    that now is dependent on the "virt_type".
    Closes-Bug: #1298242
    Change-Id: Id54f7bdfa14a19da41da554b13ba9496ee525c71

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/nova 13.0.0.0b3 development milestone.