yahoo-eng-team team mailing list archive

[OpenStack Infra <1785776@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.openstack.org/589425
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=3311d579db2482c5d06cd4e245da57333b79a8db
Submitter: Zuul
Branch:    master

commit 3311d579db2482c5d06cd4e245da57333b79a8db
Author: Balazs Gibizer <balazs.gibizer@xxxxxxxxxxxx>
Date:   Tue Aug 7 12:57:47 2018 +0200

    Fix resize revert to use non-legacy alloc handling
    
    During the revert of resize or migrate nova tries to drop the
    allocation on the target host. But first it decides if the resize uses
    the new style allocation handling where the source host allocation is
    held by the migration. If not then the legacy double-up allocation
    handling is triggered.
    
    However the implementation tried to check if the migration holds
    allocation on the destination host and that is clearly wrong as migration
    only holds alloction on the source host.
    
    This patch now changes the check to simply assert if there is any
    allocation held by the migration.uuid.
    
    Change-Id: I41c10ca5caa01dda950dd17319889963850fed59
    Closes-Bug: #1785776


** 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/1785776

Title:
  resize revert still hitting the legacy allocation handling

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  During reverting a resize or a migration Nova still hits the legacy
  allocation handling code even if the migration is started without any
  old compute or controller in the system. Search for "Doing legacy
  allocation math" in [2] for examples.

  It is caused by a faulty logic in compute manager[1]. It tries to
  decide if the reverted migration holds allocation or not to see if the
  migration is a legacy one or not. However in case of [1] the cn_uuid
  points to the destination node. Migration never holds allocation on
  the destination node so the condition at L3955 never be true and the
  code falls to the legacy path.

  It seems that the legacy path still able to handled the allocation
  properly in the above case so no resource is leaked.

  [1] https://github.com/openstack/nova/blob/8688b25ca7379391cba28fab30b5a628957e673e/nova/compute/manager.py#L3952-L3955
  [2] http://logs.openstack.org/72/587772/1/check/neutron-tempest-multinode-full/0a2fb57/logs/screen-n-cpu.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1785776/+subscriptions