VMAX: initialize/terminate can fail with 'storage group already contains'...
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
New
|
Undecided
|
Helen Walsh |
Bug Description
In VMAX volumes, sometimes we see the following failure during initialize_
ERROR ... Volume already in target SG: OS-no_SLO-SG. Message received: Bad or unexpected response from the storage volume backend API: Error modify storagegroup resource. The status code received is 500 and the message is {u'message': u'A problem occurred modifying the storage group resource: Storage Group [OS-no_SLO-SG] already contains the following volumes : [00112]'}.: VolumeBackendAP
For example, on a detach in a multi-attach situation, the flow again triggers a “move” operation rather than a plain “remove” of the vol from the SG. So it attempts to move the volume to the default group. But it is already in the default group. We have determined the logical location of the problem to be in REST utility method move_volume_
1. tolerate the error
2. check to see if the volume is still in the source group, because it could be in both, and for the move operation, it needs to be removed from the source, the code can do that if it is in both the source and target.
Handling this way has the advantage of not needing to check the exact location status of the volume up front and avoid race conditions with it for operations that might be in parallel.
tags: | added: dell drivers powermax vmax |
description: | updated |
Changed in cinder: | |
assignee: | nobody → Helen Walsh (walshh2) |
Hi Veda,
Apologies for not responding to this bug before now. Which version of OpenStack was this bug filed against?