Bug 1693338 - [OSP13] When a a storagegroup is destroyed because it's empty, VNX driver doesn't recreate it upon subsequent attachment
Summary: [OSP13] When a a storagegroup is destroyed because it's empty, VNX driver doe...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-cinder
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 13.0 (Queens)
Assignee: Pablo Caruana
QA Contact: Tzach Shefi
Tana
URL:
Whiteboard:
Depends On: 1684220
Blocks: 1682647
TreeView+ depends on / blocked
 
Reported: 2019-03-27 15:08 UTC by Pablo Caruana
Modified: 2019-04-30 17:22 UTC (History)
7 users (show)

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`.
Clone Of: 1684220
Environment:
Last Closed: 2019-04-30 17:21:49 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1817385 0 None None None 2019-03-27 15:36:10 UTC
OpenStack gerrit 642613 0 None stable/queens: MERGED cinder: VNX: update sg in cache (Ibb39879a77c97c6a5d885461e93116810d16b265) 2019-04-05 11:19:51 UTC
Red Hat Product Errata RHBA-2019:0929 0 None None None 2019-04-30 17:22:00 UTC

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


Note You need to log in before you can comment on or make changes to this bug.