storpool driver: fix the retype volume flow

Bug #2002995 reported by Peter Penchev
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Cinder
In Progress
Medium
Unassigned

Bug Description

When the type of a StorPool-backed Cinder volume is changed to another one that still uses the StorPool backend, but a different StorPool template, there are several issues that may cause the "retype volume" operation to fail or leave the wrong (old) volume attached to StorPool clients:
- the StorPool driver performs too many checks for the "differences in the volume types' extra specs fields" dictionary instead of ignoring any extra specs it does not know about and leaving it to the Cinder scheduler to decide whether those are important enough to deny the retype operation
- the return values (old volume / temporary volume / new volume) in some code paths are wrong, so sometimes the old volume (the one using the old volume type / StorPool template) may remain attached to the client

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to cinder (master)

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/cinder/+/870551

Changed in cinder:
status: New → In Progress
Changed in cinder:
importance: Undecided → Medium
tags: added: drivers storpool
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.