Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1693338

Summary:	[OSP13] When a a storagegroup is destroyed because it's empty, VNX driver doesn't recreate it upon subsequent attachment
Product:	Red Hat OpenStack	Reporter:	Pablo Caruana <pcaruana>
Component:	openstack-cinder	Assignee:	Pablo Caruana <pcaruana>
Status:	CLOSED ERRATA	QA Contact:	Tzach Shefi <tshefi>
Severity:	high	Docs Contact:	Tana <tberry>
Priority:	high
Version:	13.0 (Queens)	CC:	abishop, amcleod, cinder-bugs, dvd, tberry, tshefi, vincent.chen1
Target Milestone:	---	Keywords:	OtherQA, Triaged, ZStream
Target Release:	13.0 (Queens)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openstack-cinder-12.0.6-1.el7ost	Doc Type:	Bug Fix
Doc Text:	Previously, when `destroy_empty_storage_group` was enabled and a storage group was destroyed after it was emptied, the VNX driver or storops cache was not updated and the driver did not recreate the storage group upon subsequent attachment. The storage group cache was not updated, causing the subsequent attachment of volumes to the same host to fail. With this update, the storage group is updated with poll after deleting it. The storage group is not deleted from cache explicitly, but the status is set to `not-exist`. As a result, subsequent attaching creates the storage group if the latest status is `not-exist`.	Story Points:	---
Clone Of:	1684220	Environment:
Last Closed:	2019-04-30 17:21:49 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1684220
Bug Blocks:	1682647

Comment 4 Pablo Caruana 2019-03-27 15:56:45 UTC

Description of problem:

When we enable destroy_empty_storage_group and a storage group is destroyed after it's emptied, the VNX driver or storops cache isn't updated and the driver doesn't recreate the storage group upon subsequent attachment.

How reproducible:
100%

Steps to Reproduce:
1. Enable destroy_empty_storage_group initiator_auto_deregistration in vnx driver configuration
2. Delete attachment of all volumes on a compute node until it's deregistered by the driver
3. Attempt to re-attach a volume on deregistered compute node.

Actual results:
~~~
2019-02-25 17:11:30.089 10661 ERROR oslo_messaging.rpc.server ImageCopyFailure: Failed to copy image to volume: Bad or unexpected response from the storage volume backend API: Unable to fetch connection information from backend: Error: storagegroup command failed
2019-02-25 17:11:30.089 10661 ERROR oslo_messaging.rpc.server The group name or UID does not match any storage groups for this array
~~~

Expected results:
It should work

Comment 11 errata-xmlrpc 2019-04-30 17:21:49 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0929