retype ignores extra_specs info including backend_name
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
Fix Released
|
Undecided
|
John Griffith | ||
Kilo |
Fix Released
|
Undecided
|
John Griffith |
Bug Description
I believe this is one of the root causes of https:/
The issue is that the addition of migration to retype has no check with the filter scheduler to check if types are supported on the backend that the caller is trying to retype the volume on. So for example:
Using two volume-backends (lvm and lvm-2):
Create types'lvm' and 'lvm-2'
Associate extra_specs volume_
Now create a volume of type lvm
Now retype the volume to lvm-2
The call here: https:/
Sends a direct call to the driver to do the retype, ignoring the fact that the new_type may specify unsupported capabilities and that the types may specify contradicting backends.
The worst part of this is that most drivers don't check any of this, they just filter through what's valid and try to set it, they won't raise or error out (and I think that's ok; they should be able to trust that a request sent to them is somewhat valid). The result is that this method says "ok, it worked" and changes all the info in he database, however the volume is STILL on the original backend and our DB now has it listed on a different host.
This is why folks were seeing things like "cleanup of the original volume failed". We believed this to be an issue with the migration_
To fix this properly we should re-evaluate how we're doing retype and in particular retype with migration and make sure we involve the filter-scheduler to check the validity of things. In the short term, at least filter on volume_backend_name and require a match.
Changed in cinder: | |
milestone: | none → liberty-1 |
status: | Fix Committed → Fix Released |
Changed in cinder: | |
milestone: | liberty-1 → 7.0.0 |
Fix proposed to branch: master /review. openstack. org/181079
Review: https:/