VMAX: initialize/terminate can fail with 'storage group already contains'...

Bug #1843980 reported by Veda Annayappa
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Cinder
New
Undecided
Helen Walsh

Bug Description

In VMAX volumes, sometimes we see the following failure during initialize_connection or terminate_connection():

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]'}.: VolumeBackendAPIException: 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]'}.

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_between_storage_groups(). If that function fails for any reason, it raises the exception. But for the case when the volume is already in the target storage group, the method should:

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
Veda Annayappa (vedanu)
description: updated
Helen Walsh (walshh2)
Changed in cinder:
assignee: nobody → Helen Walsh (walshh2)
Revision history for this message
Helen Walsh (walshh2) wrote :

Hi Veda,
Apologies for not responding to this bug before now. Which version of OpenStack was this bug filed against?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.