Volume Retype with encryption fails.

[Manish]

Found the below issue with HPE driver but appears applicable to all.

Pre-requisites:
1) Volume migration requires that you have the Dynamic Optimization license installed on the HPE 3PAR Storage array.
2) 3parFC-1 and 3parFC-2 backends must be configured and enabled with encryption (LuksEncryptor).
3) 3parFC-1 and 3parFC-2 backends have the same volume_backend_name in the cinder.conf.
4) Volume type of 3parFC-1 must contain ""thin"" provisioning type and "minBWS1 and minIOPS1" QoS settings.
5) Volume type of 3parFC-2 must contain ""full"" provisioning type and "minBWS2 and minIOPS2" QoS settings.

Steps to Reproduce:

1. SSH Devstack Host IP using SSH Client via Valid user credentials.
2. Create a volume <volume1> with volume type 3parFC-1.
Run this command: cinder create --volume-type 3parFC-1 --name volume1 <size>

3. Perform Volume Retype.
Run the command: cinder retype --migration-policy on-demand <volume1> <3parFC-2 volume type>

4. Verify the retyped volume in 3par array via CLI using valid user credentials.
Run this command: showvv

5. Verify the volume type for <volume1>.
Run this command: cinder show <volume>

Expected Result:

Volume1 must be retyped and displayed in 3par array with correct details of provisioning type and QoS settings of 3parFC-2 volume type.

Observed Result:

Volume retype fails with error “ERROR: Invalid input received: Retype cannot change encryption requirements”.

[Lee Yarwood (lyarwood)]

Why was this bug created against Nova? AFAICT this behaviour appears correct assuming the two volume types have differing encryption or QoS properties :

https://github.com/openstack/cinder/blob/362062935b87d97a2ce94a648c6dea67f9afe37e/cinder/volume/api.py#L176

https://github.com/openstack/cinder/blob/362062935b87d97a2ce94a648c6dea67f9afe37e/cinder/volume/api.py#L1568

[Sean McGinnis (sean-mcginnis)]

Manish, can you confirm - are these using the same or different encryption?

[Manish (deolalkar-manish)]

HI Sean, they are using the same encryption algorithm but different QOS.

[Manish (deolalkar-manish)]

HI Lee,

The encryption algorithm are same here.
For QOS as well, we tried with same QOS but still the issue was same.
Please can you help getting assigned.

Thanks,
Manish

[Vivek Soni (viveksoni)]

With similar scenario with FC protocol without QOS setting,
Volume type of 3parFC-1 + "thin" provisioning type
Volume type of 3parFC-2 + "full" provisioning type

After volume retype from 3parFC-1 to 3parFC-2 i got below 'cryptsetup' command error :
Command: cryptsetup --batch-mode luksFormat --key-file=- --cipher aes-xts-plain64 --key-size 256 /dev/sdd
Exit code: 5
Stdout: u''
Stderr: u'Cannot format device /dev/sdd which is still in use.\n'

[Sean McGinnis (sean-mcginnis)]

Unassigning due to no activity for > 6 months.

[Raghavendra Tilay (raghavendrat)]

Observed that failure occurs when volume is attached to host.
bug: 1809249 resolves this issue. It is present in Train.
After applying this fix, volume retype happens successfully.

[Raghavendra Tilay (raghavendrat)]

Refer attached word doc for detailed output.