There's a problem with live block migrations. They can take an arbitrarily long time to complete. That, in itself, isn't the matter:
https://bugs.launchpad.net/nova/+bug/1286142 At the moment, nova.compute.manager.live_migration takes a context, which it passes into a call to its driver's live_migration method. That'll end up calling back to one of nova.compute.manager.{_post_live_migration,_rollback_live_migration} - passing that credential along. If the credential's expired, in the meantime, then the post- steps will fail as they attempt to finish up the migration. There appear, fundamentally, to be three approaches to take with this. The first is to bake sufficient admin credentials (for the block and the network layers) into the nova process so that it can run the cleanup with appropriate rights. The second would be to have a way for the nova process to extend proxy credentials until such point as they are required by the post- stages. I'll elide the potential security concerns over putting such an API call into keystone, but it should probably be considered. I suppose the third way is to have a way for a client to continue to inject live tokens into a running migration process - thereby shifting the burden onto an external person/process/entity who's driving the live migration. This all potentially being contentious, I'm basically soliciting opinions on avenues for this. With thanks in advance for your time, jan -- Jan Grant ([email protected]; [email protected]) ...and then three milkmaids turned up (to the delight and delactation of the crowd). _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
