yahoo-eng-team team mailing list archive

[Elod Illes <1879787@xxxxxxxxxxxxxxxxxx>]

** Also affects: nova/ussuri
   Importance: Undecided
       Status: New

** Also affects: nova/stein
   Importance: Undecided
       Status: New

** Also affects: nova/rocky
   Importance: Undecided
       Status: New

** Also affects: nova/train
   Importance: Undecided
       Status: New

** Changed in: nova/stein
       Status: New => Fix Released

** Changed in: nova/rocky
       Status: New => Fix Committed

** Changed in: nova/train
       Status: New => Fix Committed

** Changed in: nova/ussuri
       Status: New => Fix Committed

-- 
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
Status in OpenStack Compute (nova) rocky series:
  Fix Committed
Status in OpenStack Compute (nova) stein series:
  Fix Released
Status in OpenStack Compute (nova) train series:
  Fix Released
Status in OpenStack Compute (nova) ussuri series:
  Fix Committed

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