Bug 1872549 - CSO status of oVirt cluster looks a little of confusion: "DefaultStorageClassControllerAvailable: No default StorageClass for this platform"
Summary: CSO status of oVirt cluster looks a little of confusion: "DefaultStorageClass...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Storage
Version: 4.6
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: 4.6.0
Assignee: Christian Huffman
QA Contact: Qin Ping
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-08-26 03:48 UTC by Qin Ping
Modified: 2021-03-24 08:53 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-10-27 16:33:36 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift cluster-storage-operator pull 85 0 None closed Bug 1872549: Updated error message when SC is installed via CSI 2021-02-11 16:44:03 UTC
Red Hat Product Errata RHBA-2020:4196 0 None None None 2020-10-27 16:33:37 UTC

Description Qin Ping 2020-08-26 03:48:42 UTC
Description of problem:
In the oVirt cluster, cluster storage operator will not create storage class directly, so from this point, the stauts reports "DefaultStorageClassControllerAvailable: No default StorageClass for this platform" is correct, but the oVirt csi operator managed by CSO will create a default storage class, it makes this status looks a little of confusion.

Version-Release number of selected component (if applicable):
4.6.0-0.nightly-2020-08-26-010422

How reproducible:
Always

Steps to Reproduce:
1.Have an OCP46 cluster on oVirt
2.Check the CSO status
3.Check the storage class

Actual results:
$ oc get co storage -ojson |jq .status
{
  "conditions": [
    {
      "lastTransitionTime": "2020-08-26T01:40:46Z",
      "reason": "AsExpected",
      "status": "False",
      "type": "Degraded"
    },
    {
      "lastTransitionTime": "2020-08-26T01:55:37Z",
      "reason": "AsExpected",
      "status": "False",
      "type": "Progressing"
    },
    {
      "lastTransitionTime": "2020-08-26T01:55:37Z",
      "message": "DefaultStorageClassControllerAvailable: No default StorageClass for this platform",
      "reason": "AsExpected",
      "status": "True",
      "type": "Available"
    },
...

$ oc get sc
NAME                     PROVISIONER     RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
ovirt-csi-sc (default)   csi.ovirt.org   Delete          Immediate           false                  85m


Expected results:

Master Log:

Node Log (of failed PODs):

PV Dump:

PVC Dump:

StorageClass Dump (if StorageClass used by PV/PVC):

Additional info:

Comment 3 Christian Huffman 2020-09-04 19:30:31 UTC
I tested this on an AWS cluster (disabling SC creation here), and confirmed that we're updating the Available condition's message to be a bit more explicit. A PR [1] has been submitted to merge these changes, which should resolve them in oVirt as well.

[1] https://github.com/openshift/cluster-storage-operator/pull/85

Comment 5 Qin Ping 2020-09-14 01:36:10 UTC
Verified with: 4.6.0-0.nightly-2020-09-12-164537

"message": "DefaultStorageClassControllerAvailable: StorageClass provided by supplied CSI Driver instead of the cluster-storage-operator".

Comment 8 errata-xmlrpc 2020-10-27 16:33:36 UTC
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


Note You need to log in before you can comment on or make changes to this bug.