b8610a01b6
This is a revision of I2532cfc9b98788a1a1e765f07d0c9f8c98bc77f6 that corrects the issue that forced it to be reverted by I893105cbd270300be9ec48b3127e66022f739314. The revised code avoids attempting driver assisted migration when the volume has attachments. When doing a retype of a volume that requires a migration, the manager only uses driver assisted migration when the source and the destination belong to the same backend (different pools). As long as the volume has no attachments, driver assisted migration should also be tried for other cases, just like when we do a normal migration. One case were this would be beneficial is when doing migrations from one pool to another on the same storage system on single pool drivers (such as RBD/Ceph). This patch checks what are the changes between the types to see if it is safe to use driver assisted migration (from the perspective of keeping the resulting volume consistent with the volume type) and when it is it tries to use it. If driver assisted migration indicates that it couldn't move the volume, then we go with the generic volume migration like we used to. Co-Authored-By: Alan Bishop <abishop@redhat.com> Closes-Bug: #1886543 Change-Id: I0c6b2c584e8e0053ad740ee25f29ca1d442bdeea
8 lines
271 B
YAML
8 lines
271 B
YAML
---
|
|
fixes:
|
|
- |
|
|
`Bug #1886543 <https://bugs.launchpad.net/cinder/+bug/1886543>`_:
|
|
On retypes requiring a migration, try to use the driver assisted mechanism
|
|
when moving from one backend to another when we know it's safe from the
|
|
volume type perspective.
|