VMAX driver - conflicting threads effecting rollback

There is an issue where conflicting threads tried to act on the same
VMAX volume in certain rollback situations (i.e. one process returns
it to the default storage group while the other process deletes it),
leading to inconsistencies later. This patch rectifies the issue by
locking the volume at the relevant method. We are directly
submitting to the stable ocata branch because our SMI-S driver has
been replaced with REST.

Change-Id: I8d5b38c7ca4ef6609e79c9368c593bc588aa97b5
Closes-Bug: #1694544
This commit is contained in:
Helen Walsh 2017-06-02 22:38:37 +00:00
parent bccd77a600
commit dfd385d09a
1 changed files with 5 additions and 2 deletions

View File

@ -1850,6 +1850,7 @@ class VMAXMasking(object):
{'volumeName': volumeInstanceName})
return None
@coordination.synchronized("emc-vol-{volumeInstance[ElementName]}")
def remove_and_reset_members(
self, conn, controllerConfigService, volumeInstance,
volumeName, extraSpecs, connector=None, reset=True):
@ -1867,6 +1868,8 @@ class VMAXMasking(object):
:param reset: reset, return to original SG (optional)
:returns: storageGroupInstanceName
"""
LOG.debug("Remove and reset members for volume %(elementName)s",
{'elementName': volumeInstance['ElementName']})
storageGroupInstanceName = None
if extraSpecs[ISV3]:
self._cleanup_deletion_v3(
@ -1875,7 +1878,8 @@ class VMAXMasking(object):
if connector:
storageGroupInstanceName = (
self._get_sg_associated_with_connector(
conn, controllerConfigService, volumeInstance.path,
conn, controllerConfigService,
volumeInstance.path,
volumeName, connector))
if storageGroupInstanceName:
self._remove_volume_from_sg(
@ -1889,7 +1893,6 @@ class VMAXMasking(object):
self._return_back_to_default_sg(
conn, controllerConfigService, volumeInstance, volumeName,
extraSpecs)
return storageGroupInstanceName
def _cleanup_deletion_v3(