Storwize volume isn't displayed as attached after successful migrate due to retype

[yixuan zhang]

1. Create type-1 on svc
2. Create type-7 on v7k
3. Create volume da057a4f-fa84-4b72-b77d-97c0be4a7f0f on type-1
4. Retype the volume from type-1 to type-7
5. There will be two volumes in the cinder list in the retyping process

------------------------------------------------------------------------------------------------------------------------
ID Status Name Size Volume Type Bootable Attached to

------------------------------------------------------------------------------------------------------------------------
00beab97-b246-4d5a-b912-4bd2ab452a92 available volumetype1111 1 type-7 false
da057a4f-fa84-4b72-b77d-97c0be4a7f0f retyping volumetype1111 1 type-1 false

6. Do attach for the volume :
stack@ubuntu1310:/etc/cinder$ nova volume-attach 58dde473-010b-4703-ac80-4a423f8d99fb 00beab97-b246-4d5a-b912-4bd2ab452a92

7. Check the volume status after retype finished, it was found:
da057a4f-fa84-4b72-b77d-97c0be4a7f0f available volumetype1111 1 type-7 false 58dde473-010b-4703-ac80-4a423f8d99fb

The status for the volume is available, but the attached to is the hostid.
8. Do attach again for the volume, it will be refused:

stack@ubuntu1310:/etc/cinder$ nova volume-attach 58dde473-010b-4703-ac80-4a423f8d99fb da057a4f-fa84-4b72-b77d-97c0be4a7f0f
ERROR (BadRequest): Invalid volume: already attached (HTTP 400) (Request-ID: req-63c6af29-a05f-4331-98da-e2dd75e08103)

Since the attaching was successful, the status of the volume should be in-use after retyping finished.

[Avishay Traeger (avishay-il)]

Attach/detach should not be allowed during retype

[Mike Perez (thingee)]

Avishay, I think if the migrate_volume call fails in storwize driver, it'll try _migrate_volume_generic(), which calls create_export() for the volume status update in the attach for copy_volume_data(). Currently storwize returns None for create_export().

[John Griffith (john-griffith)]

this has been around forever with no activity, removing from targetting

[Jay Bryant (jsbryant)]

Tao, can you or Li Min please investigate this?

Thanks!

[TaoBai (baitao2020)]

Thanks, Jay, I will do it~

[TaoBai (baitao2020)]

I test is issue several times, but can not be reproduced

Here is my test process :
1:
cinder retype eb5c43ea-3a3f-4b77-939b-ade6fd6cebb4 driver1 --migration-policy on-demand

2.Then the status os volume become retyping, and a new volume status is attaching

+--------------------------------------+-----------+-------+------+-------------+----------+--------------------------------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to
+--------------------------------------+-----------+-------+------+-------------+----------+--------------------------------------+
| eb5c43ea-3a3f-4b77-939b-ade6fd6cebb4 | retyping | drv1 | 1 | driver2 | false | 8848c59d-0e7f-4af9-9eee-00f285b05a5e |
| 7cd4eadf-3386-4d3a-accf-9a69ac4da592 | attaching | drv1 | 1 | driver1 | false |

3. After several minutes:
+--------------------------------------+-----------+-------+------+-------------+----------+--------------------------------------+
| ID | Status | Name | Size | Volume Type | Bootable | Attached to
+--------------------------------------+-----------+-------+------+-------------+----------+--------------------------------------+
eb5c43ea-3a3f-4b77-939b-ade6fd6cebb4 | in-use | drv1 | 1 | driver1 | false | 8848c59d-0e7f-4af9-9eee-00f285b05a5e |

From the testing, the test result is as our expectation that the status is "in-use".

This case has been tested several times, but can not be reproduced. It may be fixed by some others.

So this ticket will be closed as invalid temporarily until it happens again