yahoo-eng-team team mailing list archive

[Matt Riedemann <mriedem.os@xxxxxxxxx>]

** Changed in: nova
     Assignee: Chris Friesen (cbf123) => Matt Riedemann (mriedem)

** Changed in: nova
       Status: Triaged => In Progress

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

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

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

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

Title:
  Live migration does not restrict to the original cell

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

Bug description:
  Migration operations between multiple cells is not supported in Pike,
  but the LiveMigrateTask in conductor does not restrict the
  RequestSpec.requested_destination.cell to the original cell that the
  instance is in when calling the scheduler's select_destination method.

  https://github.com/openstack/nova/blob/16.0.0.0rc1/nova/conductor/tasks/live_migrate.py#L153

  And when forcing a host during live migration, it completely bypasses
  the scheduler altogether:

  https://github.com/openstack/nova/blob/16.0.0.0rc1/nova/conductor/tasks/live_migrate.py#L91

  We could fix the former by adding the cell mapping to the
  requested_destination like for a cold migration:

  https://github.com/openstack/nova/blob/16.0.0.0rc1/nova/conductor/tasks/migrate.py#L51-L65

  As for the latter (forced host, bypass the scheduler), we could just
  leave it and let it fail - you'd likely get some kind of unhelpful RPC
  error since the computes can't talk to each other. Or we could get the
  cell mapping for the source node and destination node and verify they
  are the same and fail in a clear way if they are not.

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