In bug 1879787, the call to network_api.get_instance_nw_info() in
_post_live_migration() on the source compute manager eventually calls
out to the Neutron REST API. If this fails, the exception is
unhandled, and the migrating instance - which is fully running on the
destination at this point - will never be updated in the database.
This update normally happens later in
post_live_migration_at_destination().
The network_info variable obtained from get_instance_nw_info() is used
for two things: notifications - which aren't critical - and unplugging
the instance's vifs on the source - which is very important!
It turns out that at the time of the get_instance_nw_info() call, the
network info in the instance info cache is still valid for unplugging
the source vifs. The port bindings on the destination are only
activated by the network_api.migrate_instance_start() [1] call that
happens shortly *after* the problematic get_instance_nw_info() call.
In other words, get_instance_nw_info() will always return the source
ports. Because of that, we can replace it with a call to
instance.get_network_info().
NOTE(artom) The functional test has been excised, as in stable/train
the NeutronFixture does not properly support live migration with
ports, making the test worthless. The work to support this was done as
part of bp/support-move-ops-with-qos-ports-ussuri, and starts at
commit b2734b5a9a.
NOTE(artom) The
test_post_live_migration_no_shared_storage_working_correctly and
test_post_live_migration_cinder_v3_api unit tests had to be adjusted
as part of the backport to pass with the new code.
[1] d9e04c4ff0/nova/network/neutronv2/api.py (L2493-L2522)
Change-Id: If0fbae33ce2af198188c91638afef939256c2556
Closes-bug: 1879787
(cherry picked from commit 6488a5dfb2)
(cherry picked from commit 2c949cb3ee)
7ace26e4bc