This is an automated cleanup. This bug report has been closed because it is older than 18 months and there is no open code change to fix this. After this time it is unlikely that the circumstances which lead to the observed issue can be reproduced.
If you can reproduce the bug, please: * reopen the bug report (set to status "New") * AND add the detailed steps to reproduce the issue (if applicable) * AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>" Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON). Valid example: CONFIRMED FOR: LIBERTY ** Changed in: nova Importance: Medium => Undecided ** Changed in: nova Status: Confirmed => Expired -- 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): Expired 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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp