Description of problem (please be detailed as possible and provide log snippests): If LVMO is installed on a cluster without any default storage class, I expect that LVMO creates its storage class as the default storage class Version of all relevant components (if applicable): all Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? no Is there any workaround available to the best of your knowledge? yes, set the default storage class manually 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? yes Can this issue reproduce from the UI? yes If this is a regression, please provide more details to justify this: no regression Steps to Reproduce: 1. Install and configure LVMO on a SNO cluster without any other storage provider present 2. List storage classes Actual results: One storage class present, none is set as the default Expected results: One storage class is present and set as the default Additional info:
We are working on clean installation but there can be other SC on customer setup which is already set to default. Can you do in the code check that if there aren't any default SC set then set our to default? @nibalach
(In reply to Shay Rozen from comment #4) > We are working on clean installation but there can be other SC on customer > setup which is already set to default. Can you do in the code check that if > there aren't any default SC set then set our to default? @nibalach Yes, that is correct. While we assume that LVMO will be the only storage provisioner on the cluster,we are planning to check for existing SCs before setting the topolvm sc to default.
Are we fixing this in 4.11?
(In reply to Mudit Agarwal from comment #6) > Are we fixing this in 4.11? Yes. I've just posted the PR to the main branch(https://github.com/red-hat-storage/lvm-operator/pull/210)
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.11.0 security, enhancement, & bugfix 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-2022:6156