In this case migrate_volume_completion is not being called as part of 'Volume migrate', it's being called by the python-novaclient operation 'volume-update' which can be called by a non-admin user. The command 'volume-update takes as parameters an instance, an attached volume and a new volume; and it replaces the attached volume with the new volume. That is it does a copy - detach oldvol - attach newvol
If an admin user runs 'nova volume-update ' the operation completes successfully. But if a user that does not have admin privs runs it, the we end up in the state described above.
So I think that what is happening is that nova performs all it's operations as the necessary, elevating context as required. Then nova makes a call to the cinder api migrate_volume_completion, with the non-admin user creds. The cinder api server runs authorize() on the non admin-creds and refuses to continue.
So I think there are three questions here
1. Should the python novaclient command 'volume-update' be a non-admin operation. The nova devs I've spoken to believe that it should be available to non-admin users
2. If volume-admin is available to non-admins then should nova call the os-migrate_volume_completion api, or should it call os-detach and os-attach seperately on the old and new volumes
3. Should nova clean up volume states in the case where an error occurs towards the end of a volume operation.
For the moment I'm assuming that cinder should support nova in allowing non-admin users to run update-volume, and I'm assuming cinder should allow the non-admin user to run the os-migrate_volume_completion command.
I think the issue of nova cleaning up is an independent bug which could be raised on nova.
So, I'm preparing a patch that makes os-migrate_volume_completion a non-admin operation,
Please let me know if you think this is the wrong approach.
In this case migrate_ volume_ completion is not being called as part of 'Volume migrate', it's being called by the python-novaclient operation 'volume-update' which can be called by a non-admin user. The command 'volume-update takes as parameters an instance, an attached volume and a new volume; and it replaces the attached volume with the new volume. That is it does a copy - detach oldvol - attach newvol
If an admin user runs 'nova volume-update ' the operation completes successfully. But if a user that does not have admin privs runs it, the we end up in the state described above.
So I think that what is happening is that nova performs all it's operations as the necessary, elevating context as required. Then nova makes a call to the cinder api migrate_ volume_ completion, with the non-admin user creds. The cinder api server runs authorize() on the non admin-creds and refuses to continue.
So I think there are three questions here
1. Should the python novaclient command 'volume-update' be a non-admin operation. The nova devs I've spoken to believe that it should be available to non-admin users
2. If volume-admin is available to non-admins then should nova call the os-migrate_ volume_ completion api, or should it call os-detach and os-attach seperately on the old and new volumes
3. Should nova clean up volume states in the case where an error occurs towards the end of a volume operation.
For the moment I'm assuming that cinder should support nova in allowing non-admin users to run update-volume, and I'm assuming cinder should allow the non-admin user to run the os-migrate_ volume_ completion command.
I think the issue of nova cleaning up is an independent bug which could be raised on nova.
So, I'm preparing a patch that makes os-migrate_ volume_ completion a non-admin operation,
Please let me know if you think this is the wrong approach.