yahoo-eng-team team mailing list archive

[Matt Riedemann <mriedem.os@xxxxxxxxx>]

Public bug reported:

This was a regression introduced in Pike here:
https://review.openstack.org/#/c/416521/

The schedule_and_build_instances method in conductor was split into two
for loops, where the first loop creates the instance record in the cell
database and the cell is looked up via the host mapping for the chosen
host for that instance.

The problem is the 2nd for loop doesn't do the same cell lookup based on
the host:

https://github.com/openstack/nova/blob/b79492f70257754f960eaf38ad6a3f56f647cb3d/nova/conductor/manager.py#L1023

It just re-uses the last set cell variable from the first for loop, so
we could have a case where an instance is created in cell1, and then
another instance is created in cell2, and then when the 2nd loop maps
the first instance, it maps it to cell2 but it really lives in cell1.

Not to mention the BDMs and tags would be created in the wrong cell.

** Affects: nova
     Importance: High
     Assignee: Dan Smith (danms)
         Status: In Progress

** Affects: nova/pike
     Importance: High
         Status: Triaged


** Tags: cells conductor

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

** Changed in: nova/pike
       Status: New => Triaged

** Changed in: nova/pike
   Importance: Undecided => High

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

Title:
  Instances always get mapped into the last processed cell in conductor

Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) pike series:
  Triaged

Bug description:
  This was a regression introduced in Pike here:
  https://review.openstack.org/#/c/416521/

  The schedule_and_build_instances method in conductor was split into
  two for loops, where the first loop creates the instance record in the
  cell database and the cell is looked up via the host mapping for the
  chosen host for that instance.

  The problem is the 2nd for loop doesn't do the same cell lookup based
  on the host:

  https://github.com/openstack/nova/blob/b79492f70257754f960eaf38ad6a3f56f647cb3d/nova/conductor/manager.py#L1023

  It just re-uses the last set cell variable from the first for loop, so
  we could have a case where an instance is created in cell1, and then
  another instance is created in cell2, and then when the 2nd loop maps
  the first instance, it maps it to cell2 but it really lives in cell1.

  Not to mention the BDMs and tags would be created in the wrong cell.

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