Description of problem: Volume on VxFlex OS array not removed when it's deleted from cinder if it's craeted from a snapshot. Steps to Reproduce: 1. create a volume for test: openstack volume create --type vxflexos1 --size 16 testvol 2. create a snapshot of the volume: openstack volume snapshot create --volume testvol testvol_snap 3. restore the snapshot to a new volume: openstack volume create --snapshot testvol_snap --size 16 vol_from_snap 4. delete the volume restored from snapshot openstack volume delete vol_from_snap 5. delete the snapshot: openstack volume snapshot delete testvol_snap 6. delete the original volume: openstack volume delete testvol Actual results: The volume restored from snapshot is still on the array. Expected results: The volume restored from snapshot should not be presented on the array.
This bug is fixed by https://github.com/ivanpch/cinder/commit/42f3b668fbac55a64e56e776f4ef3a039840dd33
(In reply to Ivan Pchelintsev from comment #1) > This bug is fixed by > https://github.com/ivanpch/cinder/commit/ > 42f3b668fbac55a64e56e776f4ef3a039840dd33 In fact it is a follow-up to the backport tracked by https://bugzilla.redhat.com/show_bug.cgi?id=1777366 . The corresponding upstream stable/queens code contains the return, as well as the newer branches. Just a question: from The bug title it seems that the volumes are not working, but from the description I understand it's just a removal problem. Should the title be tuned a bit? I guess it changes also the impact of the issue.
(In reply to Luigi Toscano from comment #2) > (In reply to Ivan Pchelintsev from comment #1) > > This bug is fixed by > > https://github.com/ivanpch/cinder/commit/ > > 42f3b668fbac55a64e56e776f4ef3a039840dd33 > > In fact it is a follow-up to the backport tracked by > https://bugzilla.redhat.com/show_bug.cgi?id=1777366 . The corresponding > upstream stable/queens code contains the return, as well as the newer > branches. > > Just a question: from The bug title it seems that the volumes are not > working, but from the description I understand it's just a removal problem. > Should the title be tuned a bit? I guess it changes also the impact of the > issue. You are right, it's a follow up of the 1777366, the return statement was lost in backport and that led to the erroneous behavior. The volume is created but we don't return model update with proper VxFlex OS volume id and cannot reference to it afterwards. So the title of the bug is correct - such volume is unusable after creation from a snap.
(In reply to Luigi Toscano from comment #2) > (In reply to Ivan Pchelintsev from comment #1) > > This bug is fixed by > > https://github.com/ivanpch/cinder/commit/ > > 42f3b668fbac55a64e56e776f4ef3a039840dd33 > > In fact it is a follow-up to the backport tracked by > https://bugzilla.redhat.com/show_bug.cgi?id=1777366 . The corresponding > upstream stable/queens code contains the return, as well as the newer > branches. > > Just a question: from The bug title it seems that the volumes are not > working, but from the description I understand it's just a removal problem. > Should the title be tuned a bit? I guess it changes also the impact of the > issue. Driver was backported without return statement. The fix mentioned in my comment was done just today. Other questions were answered by Vladislav Belogrudov in the previous comment.
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-2020:2722