Created attachment 1701512 [details] The invalid SC is accepted resulting in a Rejected Backingstore In OCS UI: Backingstore creation should reject Provider :PVC with OBC only SC Description of problem (please be detailed as possible and provide log snippests): ---------------------------------------------------------------------- This BZ is raised to report the dissimilarities in behavior seen between UI and CLI process while using an invalid SC for creating PVC backed Backingstore. While verifiying the fix for Bug 1820297, following were the observations: 1. If one uses noobaa cli command to create a bakingstore with invalid StorageClass, the SC is rejected and no PVC/POD and Backingstore are created 2. If one uses UI: Installed Operators->OCS Operator->Backing Store-> create Backing Store and selects an invalid OBC only SC for creation, the UI doesn't reject this SC. This results in a Pending PVC and POD and a rejected unusable Backingstore More details here - https://bugzilla.redhat.com/show_bug.cgi?id=1820297#c10 Version of all relevant components (if applicable): ---------------------------------------------------------------------- cluster VMware+RHCOS, cluster channel: stable-4.5 OCP cluster version: 4.5.0-0.nightly-2020-07-14-213353 OCS = ocs-operator.v4.5.0-487.ci INFO[0000] CLI version: 2.3.0 INFO[0000] noobaa-image: noobaa/noobaa-core:5.5.0-rc3 INFO[0000] operator-image: noobaa/noobaa-operator:2.3.0 INFO[0000] Namespace: openshift-storage Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? ---------------------------------------------------------------------- No. But UI keeps showing the Backingstore in "Creating" phase and ultimately in Rejected phase. This is not a good user experience. UI should disallow selecting these SCs. Is there any workaround available to the best of your knowledge? ---------------------------------------------------------------------- Not known Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? ---------------------------------------------------------------------- 3 Can this issue reproducible? ---------------------------------------------------------------------- Yes Can this issue reproduce from the UI? ---------------------------------------------------------------------- Yes If this is a regression, please provide more details to justify this: ---------------------------------------------------------------------- No Steps to Reproduce: ---------------------------------------------------------------------- Tested in UI ================== A) navigated to Installed Operators->OpenShift Container Storage --> Create Backing Store 1. Tried creating a backingstore Backing Store Name* = neha Provider = PVC Storage Class = openshift-storage.noobaa.io 2. State of resources after the fix: >>oc get pvc neha-noobaa-pvc-bdb188e3 Pending openshift-storage.noobaa.io 17m >>oc get pod neha-noobaa-pod-bdb188e3 0/1 Pending 0 16m <none> <none> <none> <none> >>oc get backingstore -A NAMESPACE NAME TYPE PHASE AGE openshift-storage neha pv-pool Rejected 11m P.S: Atleast The noobaa-opearor pod did not report panic which is a good sign. Actual results: ---------------------------------------------------------------------- UI accepts an invalid SC (OBC only SC) and this results in unusable Pending & rejected resources created in the namespace. Expected results: ---------------------------------------------------------------------- Behavior should be same across CLI and UI. OCS UI should reject creation of a Backingstore with an invalid OBC only SC Additional info: ---------------------------------------------------------------------- Verification from CLI ================================= Similar creation from CLI is rejected as expected ------------------------------------------ localhost auth]$ /usr/local/bin/nooba-cli backingstore create pv-pool pool2 --num-volumes 1 --pv-size-gb 16 --storage-class openshift-storage.noobaa.io INFO[0005] ✅ Exists: NooBaa "noobaa" INFO[0006] ✅ Exists: StorageClass "openshift-storage.noobaa.io" FATA[0006] ❌ Could not set StorageClass "openshift-storage.noobaa.io" for system in namespace "openshift-storage" - as this class reserved for obc only [nberry@localhost auth]$ P.S: Bug for rejecting the other OBC only SC(ocs-storagecluster-ceph-rgw) = https://bugzilla.redhat.com/show_bug.cgi?id=1857721 ---------------------------------------------------------------------------- UI creation $ oc describe pvc neha-noobaa-pvc-fd7a632d Name: neha-noobaa-pvc-fd7a632d Namespace: openshift-storage StorageClass: openshift-storage.noobaa.io Status: Pending Volume: Labels: pool=neha Annotations: volume.beta.kubernetes.io/storage-provisioner: openshift-storage.noobaa.io/obc Finalizers: [kubernetes.io/pvc-protection] Capacity: Access Modes: VolumeMode: Filesystem Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ExternalProvisioning 4s (x10 over 2m7s) persistentvolume-controller waiting for a volume to be created, either by external provisioner "openshift-storage.noobaa.io/obc" or manually created by system administrator Mounted By: neha-noobaa-pod-fd7a632d
Created attachment 1713551 [details] UI screenshot to confirm only valid SCs are listed in drop-down verified the fix on following cluster version. The drop-down no longer lists the 2 RGW SCs while creating PV based Backingstores. Moving the BZ to verified state for OCP 4.6. $ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.6.0-0.nightly-2020-08-31-220837 True False 47h Cluster version is 4.6.0-0.nightly-2020-08-31-220837 $ oc get csv NAME DISPLAY VERSION REPLACES PHASE ocs-operator.v4.5.0-543.ci OpenShift Container Storage 4.5.0-543.ci Succeeded
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 (OpenShift Container Platform 4.6 GA Images), 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:4196