-
Bug
-
Resolution: Done
-
Major
-
None
-
None
-
None
-
False
-
None
-
False
-
No
-
Not Required
-
https://github.com/bf2fc6cc711aee1a0c2a/kas-fleetshard/pull/811, https://gitlab.cee.redhat.com/service/app-interface/-/merge_requests/48292, https://gitlab.cee.redhat.com/service/app-interface/-/merge_requests/48293, https://gitlab.cee.redhat.com/service/app-interface/-/merge_requests/48387, https://gitlab.cee.redhat.com/service/app-interface/-/merge_requests/48391
-
---
-
---
-
MK - Sprint 224, MK - Sprint 225
In https://chat.google.com/room/AAAAC9xRq10/drBfTEK7pzE, it was observed during Strimzi version upgrade that the reserved ManagedKafka status in RHOSAK's Stage environment were not "Ready" and reported an error of missing strimzi version.
"reserved-kafka-standard-1" { "kafka": "3.0.1", "kafkaIbp": "3.0", "strimzi": "strimzi-cluster-operator.v0.29.0-2" }
conditions: - lastTransitionTime: "2022-09-11T23:02:17.329049Z" message: The requested Strimzi version strimzi-cluster-operator.v0.26.0-16 is not supported reason: Error status: "False" type: Ready
From the above example, it can be observed that: the versions are set to "strimzi-cluster-operator.v0.29.0-2" while the MK status is stuck reporting on the old version: strimzi-cluster-operator.v0.26.0-16
The Control Plane always sets the versions of Strimzi/Kafka/IBP to the latest version on each reconciliation sync call from the Fleetshard sync. This means that the versions are always to the latest ready and available versions. At this point, we can consider that the reserved MK are always up to date.
We need to ensure that the status stays as Ready=True or to whichever previous status, but not an error status during versions upgrade.
The issue does not affect the working of the prewarming functionality as the pods are still running but it just means that the MK status is reporting a wrong value which needs to be addressed.
- mentioned on