Retype volumes with different encryptions¶
Enable the function that changing volume type of a volume  to another type with different encryptions.
Currently Cinder prevents retyping volumes to a volume type with different encryptions.
Customers use unencrypted volumes, but later they would like to change the volumes to encrypted.
Customers use encrypted volumes and later want to change to unencrypted.
Customers want to change encryptions of a volume.
Allow retype between encrypted and unencrypted volumes. Same as current retype mechanism, it allows to retype volumes in available and in-use volumes.
If a volume is in available status, the detailed process will be:
Create a new volume according to new volume_type.
Map the two volumes to the volume host.
Open the device with dm-crypt if volumes are encrypted. This is done through os-brick/encryptors .
Copy data from original volume to new volume.
Close dm-crypt and detach the volumes.
Delete original volume in backend storage.
If a volume is in-use status, nothing needs to change except the bug fix .
Data model impact¶
REST API impact¶
With the feature, it allows users to retype a volume to different encryptions.
Cinder needs to access encryption keys and decrypt the data.
A flag will be added to current retype notification to show whether it needs encryption change.
Other end user impact¶
During retyping volumes with different encryptions, Cinder needs to get key. But Barbican can be configued only to give key materials to tenants, not admin. This may lead that admin can’t retype volumes successfully. In such cases, Cinder will catch the exception, log the error. The volume to retype will be set to original state. As os-brick/encryptors doesn’t work on RBD, Sheepdog volumes, the function to retype such volumes to different encryptions will fail, and volumes will be set to original state.
It adds the step of encrypting/decrypting data during retype process, and the impact is dependent on the performance of encryption.
Other deployer impact¶
The feature is dependent on Castellan . Meanwhile, Barbican  is currently the only key manager backend supported by Castellan. Both the two packages are needed.
- Primary assignee:
Remove current limitation which disallows the retype.
Attach/detach encrypted volume through dm-crypt.
Unit tests need to be created to cover the code change that mentioned in “Proposed change”. New tempest test cases will be added after current retype test .
The cinder API documentation will need to be updated to describe the change.