[release-4.19] OCPBUGS-70181: OCPBUGS-70181: Unify capitalization when comparing architectures for available updates #1291
Conversation
The osusWithSingleConditionalEdge logic was broken down into smaller parts to allow for the creation of list of test cases with expected values utilized in the added test function. Introduce a test fixture to reduce the number of return values from the osusWithSingleConditionalEdge function. Assisted-by: Claude Code
Otherwise, the following condition in cincinnati.go in MultiArch clusters:
```
if desiredArch == string(configv1.ClusterVersionArchitectureMulti) && currentArch != desiredArch {
return current, []configv1.Release{current}, nil, nil
}
```
gets evaluated to:
```
if "Multi" == string(configv1.ClusterVersionArchitectureMulti) && "multi" != "Multi" {
return current, []configv1.Release{current}, nil, nil
}
```
This will cause MultiArch clusters with a set non-empty
`ClusterVersion.Spec.DesiredUpdate.Architecture` field to indefinitely
have available updates set to `[]configv1.Release{current}` because
the `"multi" != "Multi"` logic will always match.
The commit does change the default behaviour of the `getDesiredArchitecture` method. However, the method is only used once in the `syncAvailableUpdates` method and nowhere else. The commit adds the subsequent logic for evaluating a desired architecture to the method itself and implements the `getCurrentArchitecture` method. The goal is to introduces "getters" for such values where the unified capitalization is enforced, and their return values are of the same nature (e.g., "Multi", "amd64", ...).
|
@openshift-cherrypick-robot: Detected clone of Jira Issue OCPBUGS-70180 with correct target version. Will retitle the PR to link to the clone. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
Important Review skippedAuto reviews are limited based on label configuration. 🚫 Review skipped — only excluded labels are configured. (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Comment |
openshift-ci
bot
changed the title
openshift-ci-robot
added
jira/severity-moderate
|
@openshift-cherrypick-robot: This pull request references Jira Issue OCPBUGS-70181, which is invalid:
Comment The bug has been updated to refer to the pull request using the external bug tracker. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
wking
left a comment
wking
left a comment
There was a problem hiding this comment.
Clean cherry-pick of a pull request that was Verified for 4.20.9.
/jira-refresh
/lgtm
/label backport-risk-assessed
openshift-ci
bot
added
backport-risk-assessed
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: openshift-cherrypick-robot, wking The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
/jira refresh |
openshift-ci-robot
added
jira/valid-bug
|
@wking: This pull request references Jira Issue OCPBUGS-70181, which is valid. The bug has been moved to the POST state. 7 validation(s) were run on this bug
Requesting review from QA contact: DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
/verified later @jiajliu |
openshift-ci-robot
added
verified-later
verified
|
@jiajliu: This PR has been marked to be verified later by DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
/retest-required |
|
The HyperShift failures look like: and the management-cluster dump has: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1291/pull-ci-openshift-cluster-version-operator-release-4.19-e2e-hypershift/2010887286966718464/artifacts/e2e-hypershift/dump-management-cluster/artifacts/artifacts.tar | tar -xOz logs/artifacts/output/namespaces/clusters/hypershift.openshift.io/hostedclusters/d7e125562f926c7332ae-mgmt.yaml | yaml2json | jq '.status.conditions[] | select(.reason == "ClusterOperatorsNotAvailable")'
{
"lastTransitionTime": "2026-01-13T01:41:55Z",
"message": "Cluster operators console, dns, image-registry, ingress, insights, kube-storage-version-migrator, monitoring, network, openshift-samples, service-ca are not available",
"observedGeneration": 3,
"reason": "ClusterOperatorsNotAvailable",
"status": "False",
"type": "ClusterVersionSucceeding"
}
{
"lastTransitionTime": "2026-01-13T01:41:16Z",
"message": "Unable to apply 4.20.9: some cluster operators are not available",
"observedGeneration": 3,
"reason": "ClusterOperatorsNotAvailable",
"status": "True",
"type": "ClusterVersionProgressing"
}Because they had some kind of difficulty with the compute Machines that host those components: $ curl -s https://gcsweb-ci.apps.ci.l2s4.p1.openshiftapps.com/gcs/test-platform-results/pr-logs/pull/openshift_cluster-version-operator/1291/pull-ci-openshift-cluster-version-operator-release-4.19-e2e-hypershift/2010887286966718464/artifacts/e2e-hypershift/dump-management-cluster/artifacts/artifacts.tar | tar -xOz logs/artifacts/output/namespaces/clusters-d7e125562f926c7332ae-mgmt/cluster.x-k8s.io/machines/d7e125562f926c7332ae-mgmt-us-east-1a-bqmvw-c9959.yaml | yaml2json | jq '.status.v1beta2.conditions[] | select(.type == "Ready")'
{
"lastTransitionTime": "2026-01-13T01:45:04Z",
"message": "* NodeHealthy:\n * Node.Ready: container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: no CNI configuration file in /etc/kubernetes/cni/net.d/. Has your network provider started?",
"observedGeneration": 2,
"reason": "NotReady",
"status": "False",
"type": "Ready"
}I suspect the issue is 4.20.9's OCPBUGS-72411, which was why it was respun as 4.20.10 using an older nightly. I'm confident enough in this change not breaking HyperShift to override those jobs, since it's not clear to me how long a roll-forward fix will take to get into 4.20 nightlies and on to the version used for the management cluster in these HyperShift CI runs: /override ci/prow/e2e-hypershift |
|
@wking: Overrode contexts on behalf of wking: ci/prow/e2e-hypershift, ci/prow/e2e-hypershift-conformance DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
openshift-merge-bot
bot
merged commit 842a2ac
into
openshift:release-4.19
|
@openshift-cherrypick-robot: Jira Issue OCPBUGS-70181: All pull requests linked via external trackers have merged: This pull request has the DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
5 participants
This is an automated cherry-pick of #1281
/assign wking