Reviewed: https://review.opendev.org/729763 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=9f205c620e57c9af760d3b52c93a4ff6d5c0e618 Submitter: Zuul Branch: master
commit 9f205c620e57c9af760d3b52c93a4ff6d5c0e618 Author: Artom Lifshitz <[email protected]> Date: Wed May 20 17:14:47 2020 -0400 Handle Neutron errors in _post_live_migration() _post_live_migration() on the destination host has a call to self.network_api.get_instance_nw_info(), which eventually ends up calling the Neutron REST API (via nova.network.neutron.API._build_network_info_model()). Any exceptions in that call were unhandled, and caused both the server and the migration to end up in ERROR. This patch handles the error, and modifies the functional test to reflect the newly fixed behavior. Closes-bug: 1879787 Change-Id: I4c89c8ba0153ec01ff57979b9bf1cfd5b2a9da89 ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1879787 Title: post_live_migration does not handle Neutron errors Status in OpenStack Compute (nova): Fix Released Bug description: Description =========== _post_live_migration() on the destination host has a call to self.network_api.get_instance_nw_info(), which eventually ends up calling the Neutron REST API (via nova.network.neutron.API._build_network_info_model()). Any exceptions in that call are unhandled, meaning if Neutron fails we'll never reach post_live_migration_at_destination(), which is where we update the database to reflect the instance's new host and other housekeeping. IOW words, if Neutron fails we'll be left with the instance actually running on the destination, but still on the source according to the database. Steps to reproduce ================== 1. Boot an instance. 2. Live migrate it. 3. While that's happening, Neutron explodes. Expected result =============== While it's dubiously reasonnable to expect VIFs to get cleaned up correctly in such a case, Nova should at least correctly update the database to reflect where the instance is actually running - the destination. Actual result ============= The database shows the instance as running on the source. Environment =========== This is still a problem on master, but has been reported on OSP13/queens [1] [1] https://bugzilla.redhat.com/show_bug.cgi?id=1818829 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1879787/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
