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:
Moving to ocs-op since it is responsible for the uninstall sequence.
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.
Talur, any chance this can be fixed in 4.8?
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.
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.
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
(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.
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
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