Hide Forgot
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): 14 How reproducible: Always 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 http://pastebin.test.redhat.com/677486
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.