Cluster operator UI broken on OpenShift 4.2 - "Invariant Violation"

[nktl]

We are testing brand new, vanilla StroageOS deployment on OpenShift 4. 2 - when browsing cluster operator UI status URL:

https://cluster-console.app.local/k8s/ns/storageos-namespace/clusterserviceversions/storageosoperator.v1.5.1/storageos.com~v1~StorageOSCluster/example-storageos

We are getting the following error:

Oh no! Something went wrong.

Invariant Violation
Description:
Minified React error #31; visit https://reactjs.org/docs/error-decoder.html?invariant=31&args[]=object%20with%20keys%20%7BdirectfsInitiator%2C%20director%2C%20kv%2C%20kvWrite%2C%20nats%2C%20presentation%2C%20rdb%7D&args[]= for the full message or use the non-minified dev environment for full errors and additional helpful warnings.

Stack Trace:
Invariant Violation: Minified React error #31; visit https://reactjs.org/docs/error-decoder.html?invariant=31&args[]=object%20with%20keys%20%7BdirectfsInitiator%2C%20director%2C%20kv%2C%20kvWrite%2C%20nats%2C%20presentation%2C%20rdb%7D&args[]= for the full message or use the non-minified dev environment for full errors and additional helpful warnings. 
    at https://cluster-console.app.local/static/vendors~main-chunk-67899ee09ff4a8f7b1bd.min.js:104:425
    at a (https://cluster-console.app.local/static/vendors~main-chunk-67899ee09ff4a8f7b1bd.min.js:104:528)
    at po (https://cluster-console.app.local/static/vendors~main-chunk-67899ee09ff4a8f7b1bd.min.js:104:47246)
    at p (https://cluster-console.app.local/static/vendors~main-chunk-67899ee09ff4a8f7b1bd.min.js:104:48881)
    at m (https://cluster-console.app.local/static/vendors~main-chunk-67899ee09ff4a8f7b1bd.min.js:104:49983)
    at https://cluster-console.app.local/static/vendors~main-chunk-67899ee09ff4a8f7b1bd.min.js:104:51959
    at wi (https://cluster-console.app.local/static/vendors~main-chunk-67899ee09ff4a8f7b1bd.min.js:104:58902)
    at Mi (https://cluster-console.app.local/static/vendors~main-chunk-67899ee09ff4a8f7b1bd.min.js:104:67287)
    at Va (https://cluster-console.app.local/static/vendors~main-chunk-67899ee09ff4a8f7b1bd.min.js:104:90685)
    at qa (https://cluster-console.app.local/static/vendors~main-chunk-67899ee09ff4a8f7b1bd.min.js:104:91069)

The cluster seems to work fine though and we can provision volumes - so it looks like an UI glitch (although it makes it rather hard to manage / monitor state...)

[avestuk]

@nktl How are you accessing the StorageOS UI?

[nktl]

Just though default openshift web console:

Clicking it results with the following:

[avestuk]

@nktl I think that may be the issue then. The example-storageos resource is a CustomResource called StorageOSCluster that the StorageOS operator acts on to create a StorageOS cluster.

The StorageOS UI is available on any node running StorageOS on port 5705. You can access the StorageOS UI through the StorageOS service, using port-forwarding or perhaps it works via the Openshift UI. Alternatively, you can access your Nodes directly you can try <NODE-IP>:5705 to get to the browser.

[nktl]

Thanks, the funny thing is that the link/view in question actually works when cluster is in provisioning state, then it breaks after deployment is completed - so it looks like some value from the completed deployment is bugging it out - so might be worth investigating still. You are correct however that I misnamed this thing 'UI', it seems to be just a cluster status page.

On the actual UI front, it looks to be operational - but I am not exactly sure what the creds are, the ones from the documentation (storageos/storageos) do not seem to work, neither the api creds set during the provisioning process.

[avestuk]

Thanks, the funny thing is that the link/view in question actually works when cluster is in provisioning state, then it breaks after deployment is completed

That's very useful to know - thank you!

The credentials for the UI are what you created in step 5 if you followed the Openshift 4.1 docs. If not then it's the apiUsername and apiPassword that are defined in the secret that you created as part of the installation process.

[croomes]

Hi @nktl, thanks for raising this. We're going to try and reproduce this - it looks like an Openshift error but we might be passing it data in the wrong format. We made some changes to the status format recently (to be more compliant with Openshift!)