Description of problem (please be detailed as possible and provide log snippests): In the provider cluster, the backingstore "noobaa-default-backing-store" is created on a pv-pool instead of RGW. $ oc get backingstore -n openshift-storage NAME TYPE PHASE AGE noobaa-default-backing-store pv-pool Ready 4d2h $ oc get pods -o wide -n openshift-storage | grep rgw rook-ceph-rgw-ocs-storagecluster-cephobjectstore-a-7b98c64sm7nf 2/2 Running 883 (23h ago) 4d2h 52.116.161.166 baremetal2-05.qe.rh-ocs.com <none> <none> ============================================================ Version of all relevant components (if applicable): $ oc get csv NAME DISPLAY VERSION REPLACES PHASE mcg-operator.v4.14.4-5.fusion-hci NooBaa Operator 4.14.4-5.fusion-hci mcg-operator.v4.14.3-rhodf Succeeded metallb-operator.v4.14.0-202311302149 MetalLB Operator 4.14.0-202311302149 Succeeded ocs-operator.v4.14.4-5.fusion-hci OpenShift Container Storage 4.14.4-5.fusion-hci ocs-operator.v4.14.3-rhodf Succeeded odf-csi-addons-operator.v4.14.4-5.fusion-hci CSI Addons 4.14.4-5.fusion-hci odf-csi-addons-operator.v4.14.3-rhodf Succeeded odf-operator.v4.14.4-5.fusion-hci OpenShift Data Foundation 4.14.4-5.fusion-hci odf-operator.v4.14.3-rhodf Succeeded $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.14.7 True False 5d23h Cluster version is 4.14.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? No Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? 1 Can this issue reproducible? Reporting the first occurance Can this issue reproduce from the UI? If this is a regression, please provide more details to justify this: Steps to Reproduce: 1. Create provider-client setup. 2. On provider cluster, run oc get backingstore noobaa-default-backing-store -n openshift-storage 3. Check whether noobaa-default-backing-store is on RGW or not. Actual results: Type of noobaa-default-backing-store is "pv-pool". Expected results: noobaa-default-backing-store should be on RGW isntead of pv-pool Additional info: IBM BM platform is used.
Adding yaml output of backingstore noobaa-default-backing-store which is missing in bug Description. $ oc get backingstore noobaa-default-backing-store -n openshift-storage -o yaml apiVersion: noobaa.io/v1alpha1 kind: BackingStore metadata: creationTimestamp: "2024-01-13T10:14:10Z" finalizers: - noobaa.io/finalizer generation: 1 labels: app: noobaa name: noobaa-default-backing-store namespace: openshift-storage ownerReferences: - apiVersion: noobaa.io/v1alpha1 blockOwnerDeletion: true controller: true kind: NooBaa name: noobaa uid: 4b48f1ab-6997-4833-886b-81fbecfb6f5f resourceVersion: "6292643" uid: eca8228f-1926-4a52-bba4-cc5c6c59b622 spec: pvPool: numVolumes: 1 resources: requests: storage: 50Gi secret: {} storageClass: ocs-storagecluster-ceph-rbd type: pv-pool status: conditions: - lastHeartbeatTime: "2024-01-17T12:56:55Z" lastTransitionTime: "2024-01-17T12:56:55Z" message: BackingStorePhaseReady reason: 'Backing store mode: OPTIMAL' status: "True" type: Available - lastHeartbeatTime: "2024-01-17T12:56:55Z" lastTransitionTime: "2024-01-17T12:56:55Z" message: BackingStorePhaseReady reason: 'Backing store mode: OPTIMAL' status: "False" type: Progressing - lastHeartbeatTime: "2024-01-17T12:56:55Z" lastTransitionTime: "2024-01-17T09:49:15Z" message: BackingStorePhaseReady reason: 'Backing store mode: OPTIMAL' status: "False" type: Degraded - lastHeartbeatTime: "2024-01-17T12:56:55Z" lastTransitionTime: "2024-01-17T12:56:55Z" message: BackingStorePhaseReady reason: 'Backing store mode: OPTIMAL' status: "True" type: Upgradeable mode: modeCode: OPTIMAL timeStamp: 2024-01-17 09:49:15.786131426 +0000 UTC m=+348024.816926495 phase: Ready
Moving the non-blocker BZ out, please bring it back with a blocker justification if required.
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 (Important: Red Hat OpenShift Data Foundation 4.16.0 security, enhancement & 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-2024:4591