openstack/nova
Code Issues Proposed changes

Make swap-volume an admin-only API by default

Browse Source 
Cinder's volume migration API is, by default, an admin-only operation.
This includes the migrate_volume_completion API.

When Cinder is doing a volume migration, it calls Nova's swap-volume
API to detach the old volume that we're migrating from and attach
the volume that we're migrating to. Then Nova calls Cinder's
migrate_volume_completion API to signal Nova is done and Cinder
can finish the volume migration.

The problem is that swap-volume is not an admin-only API in Nova
per the default policy. So if a non-admin user tries to perform
a swap-volume operation, it will fail with a 403 when calling
Cinder's migrate_volume_completion API, since that requires an
admin user.

Also, because of 98739761f1 we can't
simply avoid calling migrate_volume_completion for non-migration
cases because that API handles the actual detach/attach for the old
and new volumes, swap-volume is broken without calling that.

So given swap-volume relies on an admin-only Cinder API, and is called
from an admin-only Cinder operation (volume migration), we should
just make it default to admin-only also.

Change-Id: Iac03258735f3d856a474ab96fe9b0a087e32906f
Closes-Bug: #1522705
This commit is contained in:
Matt Riedemann
2016-03-30 22:07:47 -04:00
parent 7c648c3bc1
commit f738483e84
4 changed files with 18 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
doc/source/support-matrix.ini
View File

@@ -498,13 +498,14 @@ driver-impl-libvirt-vz-ct=complete
[operation.swap-volume]
title=Swap block volumes
status=optional
notes=The swap volume operation is a mechanism for changing running
notes=The swap volume operation is a mechanism for changing a running
instance so that its attached volume(s) are backed by different
storage in the host. An alternative to this would be to simply
terminate the existing instance and spawn a new instance with the
new storage. In other words this operation is primarily targeted towards
the pet use case rather than cattle. Therefore this is considered
optional to support.
the pet use case rather than cattle, however, it is required for volume
migration to work in the volume service. This is considered optional to
support.
cli=
driver-impl-xenserver=missing
driver-impl-libvirt-kvm-x86=complete