Incorrect configuration of StatefulSet “rhm-data-service” in the SNO scenario

[diegovisentin]

MAS CLI version

15.8.0

CLI function used

install

What happened?

The "rhm-data-service" stateful set, which is created during installation of the IBM Metrics Operator, does not seem to adapt to a Single Node OpenShift (SNO) installation. The replicas are set to three with podAntiAffinity constraints that cannot be addressed. P.S. This also affects the MAS update pre-checks, which fail to detect the three pods.

Relevant log output

TASK [ibm.mas_devops.ocp_verify : Check Deployment & StatefulSet Status] *******
Checking Deployments are healthy (1/40 retries with a 300 second delay)
Finished check: All workloads are healthy
Success: allResourcesHealthy=True
Checking StatefulSets are healthy (1/40 retries with a 300 second delay)
[DISABLED] mongoce/mas-mongo-ce-arb = 0 replicas/0 available
[NOTREADY] redhat-marketplace/rhm-data-service = 3 replicas/2 ready/None updated/2 available
Finished check: Delaying 300 seconds before next check
Checking StatefulSets are healthy (2/40 retries with a 300 second delay)
[DISABLED] mongoce/mas-mongo-ce-arb = 0 replicas/0 available
[NOTREADY] redhat-marketplace/rhm-data-service = 3 replicas/2 ready/None updated/2 available
Finished check: Delaying 300 seconds before next check
Checking StatefulSets are healthy (3/40 retries with a 300 second delay)
[DISABLED] mongoce/mas-mongo-ce-arb = 0 replicas/0 available
[NOTREADY] redhat-marketplace/rhm-data-service = 3 replicas/2 ready/None updated/2 available
Finished check: Delaying 300 seconds before next check

[pgodowski]

Is there a chance the workaround is applied, i.e. pinned CatalogSource for IBM Metrics operator, to deploy earlier version of Metrics Operator please?

[pgodowski]

Temporary work-around for impacted environments. It is ONLY for SingleNodeOpenshift (SNO) - it's not required it seems on Openshift with 2 or more worker nodes.

1. Scale IBM Metrics Operator to zero (edit its Deployment, set replicas: 0)
2. Manually edit rhm-data-service StatefulSet, removing podAntiAffinity section

[diegovisentin]

@pgodowski Thank you very much for this clever workaround! I can confirm that it allows you to bypass the verification on the 3 active pods of the rhm-data-service StatefulSet, enabling the pipeline to proceed with the next installation steps. I therefore look forward to seeing this problem "officially" resolved at its root in future versions.