I think this should be validated in backend.
Do you have a default storage class in your system ? Ideally the default storage class is show in the dropdown if present
Thats with the flow then. We are using generic OCP component, which shows default storage class as first selected class , if present. Otherwise one will see this.
Very unlikely that customer run into this in normal cases. We will add some validation(either in UI or operator) but not a blocker for 4.3 Moving out of 4.3
It requires change in a console component hence we will take this as an enhancement for OCP 4.5 as thats the window we have available.
*** Bug 1810031 has been marked as a duplicate of this bug. ***
I performed the following steps to reproduce the bug: 1. Navigate to Installed Operators -> OpenShift Container Storage -> Storage Gluster 2. Clicking on the add capacity button. 3. In the storage class field choosing the "No default storage class" option and clicking on the "Add" button. The result: The installation didn't proceed, and it returned an error: "No StorageClass selected". Versions I used to check the bug: OCP version: Client Version: 4.3.8 Server Version: 4.5.0-0.nightly-2020-06-23-035950 Kubernetes Version: v1.18.3+c44581d OCS verison: ocs-operator.v4.5.0-460.ci OpenShift Container Storage 4.5.0-460.ci Succeeded cluster version NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.5.0-0.nightly-2020-06-23-035950 True False 3h51m Cluster version is 4.5.0-0.nightly-2020-06-23-035950 Rook version rook: 4.5-27.acf5b22b.release_4.5 go: go1.13.4 Ceph version ceph version 14.2.8-59.el8cp (53387608e81e6aa2487c952a604db06faa5b2cd0) nautilus (stable)
Created attachment 1698448 [details] OCS installation doesn't proceed without providing SC
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:2409