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

Bug 1682647

Summary:	[OSP10] When a a storagegroup is destroyed because it's empty, VNX driver doesn't recreate it upon subsequent attachment
Product:	Red Hat OpenStack	Reporter:	David Vallee Delisle <dvd>
Component:	openstack-cinder	Assignee:	Pablo Caruana <pcaruana>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Tzach Shefi <tshefi>
Severity:	high	Docs Contact:	Tana <tberry>
Priority:	high
Version:	10.0 (Newton)	CC:	abishop, pcaruana, pgrist, stesmith
Target Milestone:	---	Keywords:	OtherQA, TestOnly, Triaged, ZStream
Target Release:	10.0 (Newton)	Flags:	tshefi: automate_bug-
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openstack-cinder-9.1.4-51.el7ost	Doc Type:	Bug Fix
Doc Text:	This update fixes a bug that caused volume attachment failures. Prior to this update, if 'destroy_empty_storage_group' was enabled and a storage group was destroyed after it was emptied, the VNX driver or storops caches wasn't updated and the driver did not recreate the storage group upon subsequent attachment. As a result, the storage group cache was not updated, and subsequent volume attachments to the same host failed because the storage group in the cache, which did not exist anymore, was used directly. Now the storage group is updated with poll after deleting it. This doesn't delete the storage group from the cache explicitly, but makes sure the storage group is in the cache with the latest status of "not-exist." When the status is 'not-exist,' subsequent attachments will create the storage group.	Story Points:	---
Clone Of:
Clones:	1684220 (view as bug list)		Environment:
Last Closed:	2019-07-10 14:54:04 UTC	Type:	Bug
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, 1693338
Bug Blocks:

Description David Vallee Delisle 2019-02-25 18:36:28 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.

I'm not sure if it's a requisite but we had iscsi auto deregistration enabled as well.


Version-Release number of selected component (if applicable):
openstack-cinder-9.1.4-41

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

Additional info:

Comment 1 Tzach Shefi 2019-02-27 14:57:15 UTC

Close loop wise this looks more like a back end / driver issue, won't automate/test it. 

Also as won't be able to verify it(otherQA)

Comment 15 Lon Hohberger 2019-07-10 10:41:03 UTC

According to our records, this should be resolved by openstack-cinder-9.1.4-52.el7ost.  This build is available now.