Bug 1684220
| Summary: | [OSP14] 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 ERRATA | QA Contact: | Tzach Shefi <tshefi> | |
| Severity: | low | Docs Contact: | Tana <tberry> | |
| Priority: | high | |||
| Version: | 14.0 (Rocky) | CC: | abishop, cinder-bugs, jamsmith, rheslop, tberry, tshefi, vincent.chen1 | |
| Target Milestone: | --- | Keywords: | OtherQA, Triaged, ZStream | |
| Target Release: | 14.0 (Rocky) | Flags: | tshefi:
automate_bug-
|
|
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | openstack-cinder-13.0.3-2.el7ost | Doc Type: | Bug Fix | |
| Doc Text: |
Prior to this update, 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: | 1682647 | |||
| : | 1693338 (view as bug list) | Environment: | ||
| Last Closed: | 2019-04-30 17:47:26 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: | ||||
| Bug Blocks: | 1682647, 1693338 | |||
|
Comment 2
Alan Bishop
2019-03-25 16:52:03 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:0946 |