Bug 1655490 - Cinder retype does not use driver assisted volume migration
Summary: Cinder retype does not use driver assisted volume migration
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-cinder
Version: 14.0 (Rocky)
Hardware: x86_64
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Jon Bernard
QA Contact: Tzach Shefi
Kim Nylander
Depends On:
TreeView+ depends on / blocked
Reported: 2018-12-03 09:55 UTC by Gregory Charot
Modified: 2020-07-06 16:37 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Launchpad 1886543 0 None None None 2020-07-06 16:31:43 UTC
OpenStack gerrit 739548 0 None NEW Driver assisted migration on retype when it's safe 2021-01-12 10:44:22 UTC

Description Gregory Charot 2018-12-03 09:55:17 UTC
Description of problem:

OSP14 introduces RBD cinder migration driver (BZ 1262068). When performing a cinder migrate, the driver is indeed used however when doing a cinder retype it is not, the generic driver is used instead (volume is migrated through the controllers).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Define two cinder types pointing to two different cinder backends hosted on the same ceph cluster (diff pools)
cinder type-list
| ID                                   | Name     | Description          | Is_Public |
| 7b51de01-37c1-419b-85ca-dd0de7df3b2e | fast     | Fast Volume Type     | True      |
| ec995825-5232-417b-aca6-3aab621c0f7f | standard | Standard Volume Type | True      |
2. Do a cinder retype
cinder retype --migration-policy on-demand test fast
3. The migration process use the generic driver

Actual results:

Migration is not driver assisted

Expected results:

Migration should use the relevant (RBD in this case) driver.

Additional info:

Cinder volume debug logs

Comment 9 Gorka Eguileor 2019-05-16 08:53:42 UTC
I believe this is a limitation of how the features were designed.

Currently the driver optimized retype is only called if the volume is is not encrypted and if the backend doesn't change.

When the backend is different and we enable migrations then we call the normal migration, but telling it it has a new type, and this prevents the manager calling the driver optimized migration due to this check in the volume manager's `migrate_volume` method: 

        if not force_host_copy and new_type_id is None:

This is because a driver retype doesn't migrate a volume, and a migration doesn't retype a volume.

From a quick look I see 2 alternatives:

- Allow driver to opt in on a 2 step process: optimized migration and then driver specific retype.
- Call optimized migration on retype when the only difference between the types is the destination backend.

In my opinion we should enable the second option in any case, and it shouldn't bee too complicated.

Comment 17 Gorka Eguileor 2020-07-06 16:37:24 UTC
I have opened a bug upstream for the second case I mentioned on comment #9 and I have proposed a fix that should resolve most of the use cases, as it will call driver assisted migration when the volume types only change the backend, which is the case for almost all cases described in this BZ's scenario.

Note You need to log in before you can comment on or make changes to this bug.