Bug 1892709

Summary: NooBaa storage class should be deleted when uninstalling
Product: [Red Hat Storage] Red Hat OpenShift Data Foundation Reporter: Anna Sandler <asandler>
Component: Multi-Cloud Object GatewayAssignee: Nimrod Becker <nbecker>
Status: CLOSED ERRATA QA Contact: Anna Sandler <asandler>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.7CC: amagrawa, ebenahar, etamir, jrivera, kbg, madam, muagarwa, nbecker, nberry, ocs-bugs, odf-bz-bot, rayalon, rtalur, sostapov
Target Milestone: ---Flags: muagarwa: needinfo? (nberry)
Target Release: ODF 4.9.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: v4.9.0-453.ci Doc Type: Bug Fix
Doc Text:
.Multicloud Object Gateway storage class deleted during uninstall Previously, Multicloud Object Gateway (MCG) storage class which was deployed as a part of OpenShift Data Foundation deployment was not deleted during uninstall. With this update, the Multicloud Object Gateway (MCG) storage class gets removed while uninstalling OpenShift Data Foundation.
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-12-13 17:44:23 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:    
Bug Blocks: 2011326    

Description Anna Sandler 2020-10-29 13:55:52 UTC
Description of problem (please be detailed as possible and provide log
snippests):
NooBaa default storage class openshift-storage.noobaa.io  should be deleted automatically when uninstalling OCS

Version of all relevant components (if applicable):
OCS 4.7 

Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?


Is there any workaround available to the best of your knowledge?


Rate from 1 - 5 the complexity of the scenario you performed that caused this
bug (1 - very simple, 5 - very complex)?


Can this issue reproducible?


Can this issue reproduce from the UI?


If this is a regression, please provide more details to justify this:


Steps to Reproduce:
1.
2.
3.


Actual results:


Expected results:


Additional info:

Comment 2 Sébastien Han 2020-10-29 14:12:28 UTC
Moving to ocs-op since it is responsible for the uninstall sequence.

Comment 3 Jose A. Rivera 2021-02-08 15:26:16 UTC
Further investigation is still required to see where the changes should be made.

This already has a workaround as part of the uninstall documentation. Since it is not a blocker, moving this to OCS 4.8.

Comment 4 Mudit Agarwal 2021-06-04 16:55:43 UTC
Talur, any chance this can be fixed in 4.8?

Comment 5 Raghavendra Talur 2021-06-08 16:24:43 UTC
Romy,

It looks like the noobaa storageclass is created by Noobaa and not the ocs-operator. If we want to fix this, there are two possible ways:
1. ocs-op creates the storageclass instead of Noobaa and deletes it during the uninstall phase.
2. Noobaa continues to be the creator of the storageclass and deletes it when Noobaa is deleted.

Please let me know what would be your preference.

Mudit/Jose,
We need a little more info before deciding the feasibility but my opinion is that we should move this bug out of 4.8. It is not a regression and we know that the documentation we have covers this problem. It is not preventing any user from performing the uninstall operation.

Comment 6 Jose A. Rivera 2021-06-09 15:51:15 UTC
I agree with Talur's assessment. We should get @nbecker to weigh in on whether he wants to fix it in NooBaa or move it out to ocs-operator. Meanwhile, moving to ODF 4.9.

Comment 7 Nimrod Becker 2021-06-09 15:57:15 UTC
In general, we want to keep NooBaa SA for u/s so we don't want to create this dependency (when deploying) on the ocs-operator.
We already have this reported u/s and will probably fix in 4.9, see https://github.com/noobaa/noobaa-operator/issues/631#issuecomment-840118147

Comment 8 Mudit Agarwal 2021-06-10 06:06:18 UTC
(In reply to Nimrod Becker from comment #7)
> In general, we want to keep NooBaa SA for u/s so we don't want to create
> this dependency (when deploying) on the ocs-operator.
> We already have this reported u/s and will probably fix in 4.9, see
> https://github.com/noobaa/noobaa-operator/issues/631#issuecomment-840118147

Thanks Nimrod, I guess its time to change the component to MCG then.

Comment 11 Anna Sandler 2021-07-26 18:07:56 UTC
before deleting storagecluster:
[asandler@fedora ~]$ oc get storageclass -A
NAME                                PROVISIONER                             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
gp2                                 kubernetes.io/aws-ebs                   Delete          WaitForFirstConsumer   true                   166m
gp2-csi                             ebs.csi.aws.com                         Delete          WaitForFirstConsumer   true                   165m
ocs-storagecluster-ceph-rbd         openshift-storage.rbd.csi.ceph.com      Delete          Immediate              true                   133m
ocs-storagecluster-ceph-rbd-thick   openshift-storage.rbd.csi.ceph.com      Delete          Immediate              true                   133m
ocs-storagecluster-cephfs           openshift-storage.cephfs.csi.ceph.com   Delete          Immediate              true                   133m
openshift-storage.noobaa.io         openshift-storage.noobaa.io/obc         Delete          Immediate              false                  128m

running:
oc delete -n openshift-storage storagecluster --all --wait=true

after:
[asandler@fedora ~]$ oc get storageclasses -A
NAME                                PROVISIONER                             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
gp2                                 kubernetes.io/aws-ebs                   Delete          WaitForFirstConsumer   true                   176m
gp2-csi                             ebs.csi.aws.com                         Delete          WaitForFirstConsumer   true                   176m


moving bug to verified

Comment 22 errata-xmlrpc 2021-12-13 17:44:23 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 (Moderate: Red Hat OpenShift Data Foundation 4.9.0 enhancement, security, and bug fix update), 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/RHSA-2021:5086