yahoo-eng-team team mailing list archive

[jan grant <jan.grant@xxxxxx>]

Public bug reported:

A live migration of a large instance can take an arbitrarily long period
of time.

Once the underlying driver calls
nova.compute.manager._post_live_migration, the context that's passed in
may have an expired credential attached to it. That makes the calls that
the post-step runs fail.

These calls fall into two categories. The first are ones that gather
information - that information may, potentially, be gathered earlier on
as a part of the pre-migration step.

However, some of these calls (which run on both the source and
destination) ask other components to actually perform some state changes
- block device mappings and/or network state changes.


There are a number of approaches which might be taken to remedy this. For instance, keystone might be given the ability to spawn long-lived, one-shot tokens that can be renewed without the underlying credentials; the live migration process then needs to spawn and keep those tokens alive while it waits.

Alternatively, the services that migration depends upon (block
migration, network migration) could be aught about the live migration
lifecycle explicitly. (This is not a bad idea anyway.) They can use the
partial setup registered as a part of the pre-migration to authorise the
post-migration step - however, the nova layer would still need to
credential the api requests it makes to complete the live migration
process.

Finally, the nova layer could be given not only neutron but also cinder
admin credentials, which it uses for the post-migration stage.

** Affects: nova
     Importance: Undecided
         Status: New

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

Title:
  live migration (block migration) _post_live_migration may run with an
  expired token

Status in OpenStack Compute (Nova):
  New

Bug description:
  A live migration of a large instance can take an arbitrarily long
  period of time.

  Once the underlying driver calls
  nova.compute.manager._post_live_migration, the context that's passed
  in may have an expired credential attached to it. That makes the calls
  that the post-step runs fail.

  These calls fall into two categories. The first are ones that gather
  information - that information may, potentially, be gathered earlier
  on as a part of the pre-migration step.

  However, some of these calls (which run on both the source and
  destination) ask other components to actually perform some state
  changes - block device mappings and/or network state changes.

  
  There are a number of approaches which might be taken to remedy this. For instance, keystone might be given the ability to spawn long-lived, one-shot tokens that can be renewed without the underlying credentials; the live migration process then needs to spawn and keep those tokens alive while it waits.

  Alternatively, the services that migration depends upon (block
  migration, network migration) could be aught about the live migration
  lifecycle explicitly. (This is not a bad idea anyway.) They can use
  the partial setup registered as a part of the pre-migration to
  authorise the post-migration step - however, the nova layer would
  still need to credential the api requests it makes to complete the
  live migration process.

  Finally, the nova layer could be given not only neutron but also
  cinder admin credentials, which it uses for the post-migration stage.

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