Comment 4 for bug 1413610

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.