yahoo-eng-team team mailing list archive

[Matt Riedemann <mriedem.os@xxxxxxxxx>]

I pushed up a sanity check patch:

https://review.openstack.org/#/c/488187/2

for this and got a hit in the live migration job:

http://logs.openstack.org/87/488187/2/check/gate-tempest-dsvm-multinode-
live-migration-ubuntu-
xenial/107a810/logs/subnode-2/screen-n-cpu.txt.gz#_Jul_27_22_21_14_766229

Jul 27 22:21:14.766229 ubuntu-xenial-2-node-rax-iad-10131407-754260
nova-compute[921]: WARNING nova.scheduler.client.report [None req-
e1963d3c-9cb0-4980-a397-7314c7f483fa tempest-
LiveMigrationRemoteConsolesV26Test-535663336 tempest-
LiveMigrationRemoteConsolesV26Test-535663336] [instance: 6a8ff75c-
22e3-4a17-b0d3-ac1b44f9f7c3] Removing allocations for instance which are
currently against more than one compute node resource provider. Current
allocations: {u'13b1e5e0-66ef-4533-9a07-b1a3220d6b00': {u'generation':
8, u'resources': {u'VCPU': 1, u'MEMORY_MB': 64}}, u'7aa9619d-
db83-4da9-b822-f4d66e7143f8': {u'generation': 6, u'resources': {u'VCPU':
1, u'MEMORY_MB': 64}}}

I have not seen a hit on the case that the source node is deleting
allocations for an instance but the source node UUID is not part of the
current allocations, which is a race that can exist in a slow system,
but probably not slow enough for the upstream CI system which doesn't
have that much traffic.

** Tags added: compute placement resource-tracker

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

** Changed in: nova
       Status: New => Confirmed

** Changed in: nova
   Importance: Undecided => Medium

** Description changed:

  As far back as Ocata, compute nodes that manage allocations will end up
  overwriting allocations from other compute nodes when doing a migration.
  This stems from the fact that the Resource Tracker was designed to
  manage a per-compute-node set of accounting, but placement is per-
  instance accounting. When we try to create/update/delete allocations for
  instances on compute nodes from the existing resource tracker code
  paths, we end up deleting allocations that apply to other compute nodes
  in the process.
  
  For example, when an instance A is running against compute1, there is an
  allocation for its resources against that node. When migrating that
  instance to compute2, the target compute (or scheduler) may create
  allocations for instance A against compute2, which overwrite those for
  compute1. Then, compute1's periodic healing task runs, and deletes the
  allocation for instance A against compute2, replacing it with one for
  compute1. When migration completes, compute2 heals again and overwrites
  the allocation with one for the new home of the instance. Then, compute1
- may the allocation it thinks it owns, followed finally by another heal
- on compute2. While this is going on, the scheduler (via placement) does
- not have a consistent view of resources to make proper decisions.
+ may delete the allocation it thinks it owns, followed finally by another
+ heal on compute2. While this is going on, the scheduler (via placement)
+ does not have a consistent view of resources to make proper decisions.
  
  In order to fix this, we need a combination of changes:
  
  1. There should be allocations against both compute nodes for an instance during a migration
  2. Compute nodes should respect the double claim, and not delete allocations for instances it used to own, if the allocation has no resources for its resource provider
  3. Compute nodes should not delete allocations for instances unless they own the instance _and_ the instance is in DELETED/SHELVED_OFFLOADED state

-- 
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/1707071

Title:
  Compute nodes will fight over allocations during migration

Status in OpenStack Compute (nova):
  Confirmed
Status in OpenStack Compute (nova) ocata series:
  Confirmed

Bug description:
  As far back as Ocata, compute nodes that manage allocations will end
  up overwriting allocations from other compute nodes when doing a
  migration. This stems from the fact that the Resource Tracker was
  designed to manage a per-compute-node set of accounting, but placement
  is per-instance accounting. When we try to create/update/delete
  allocations for instances on compute nodes from the existing resource
  tracker code paths, we end up deleting allocations that apply to other
  compute nodes in the process.

  For example, when an instance A is running against compute1, there is
  an allocation for its resources against that node. When migrating that
  instance to compute2, the target compute (or scheduler) may create
  allocations for instance A against compute2, which overwrite those for
  compute1. Then, compute1's periodic healing task runs, and deletes the
  allocation for instance A against compute2, replacing it with one for
  compute1. When migration completes, compute2 heals again and
  overwrites the allocation with one for the new home of the instance.
  Then, compute1 may delete the allocation it thinks it owns, followed
  finally by another heal on compute2. While this is going on, the
  scheduler (via placement) does not have a consistent view of resources
  to make proper decisions.

  In order to fix this, we need a combination of changes:

  1. There should be allocations against both compute nodes for an instance during a migration
  2. Compute nodes should respect the double claim, and not delete allocations for instances it used to own, if the allocation has no resources for its resource provider
  3. Compute nodes should not delete allocations for instances unless they own the instance _and_ the instance is in DELETED/SHELVED_OFFLOADED state

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