OCPBUGS-8247: return error when --to-multi-arch is used on a multi-arch cluster

[savio87]

Summary

Running oc adm upgrade --to-multi-arch on a cluster that is already multi-architecture did not return an error. The existing check only caught the case where a migration was requested (via spec.desiredUpdate.architecture) but not yet completed. After completion, CVO clears that field, so the command would attempt the patch again.

This adds a check on status.desired.architecture to detect clusters that are already running multi-architecture and return a clear error message.

Bug: https://redhat.atlassian.net/browse/OCPBUGS-8247

Changes

• Added check: if cv.Status.Desired.Architecture == ClusterVersionArchitectureMulti, return "Cluster is already multi-architecture"
• This runs before the existing spec.desiredUpdate check, which catches in-progress migrations

[openshift-merge-bot]

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

[openshift-ci-robot]

@savio87: This pull request references Jira Issue OCPBUGS-8247, which is invalid:

• expected the bug to target the "5.0.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

Summary

Running oc adm upgrade --to-multi-arch on a cluster that is already multi-architecture did not return an error. The existing check only caught the case where a migration was requested (via spec.desiredUpdate.architecture) but not yet completed. After completion, CVO clears that field, so the command would attempt the patch again.

This adds a check on status.desired.architecture to detect clusters that are already running multi-architecture and return a clear error message.

Bug: https://redhat.atlassian.net/browse/OCPBUGS-8247

Changes

• Added check: if cv.Status.Desired.Architecture == ClusterVersionArchitectureMulti, return "Cluster is already multi-architecture"
• This runs before the existing spec.desiredUpdate check, which catches in-progress migrations

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.

[coderabbitai]

Warning

Review limit reached

@savio87, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 3 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Pro Plus

Run ID: 485849d0-3581-4cca-8baf-4450638604fc

📥 Commits

Reviewing files that changed from the base of the PR and between 9c7ccc4 and 95eb723.

📒 Files selected for processing (1)

• pkg/cli/admin/upgrade/upgrade.go

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: savio87
Once this PR has been reviewed and has the lgtm label, please assign wking for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• pkg/cli/admin/upgrade/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Hi @savio87. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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.

[savio87]

Adds a check on status.desired.architecture to detect clusters already running multi-architecture, returning a clear error instead of attempting a redundant patch. Could a maintainer update the target version on OCPBUGS-8247 and run /ok-to-test? Thanks!

[tchap]

I am not sure the message is precise, the docs say:

	// desired is the version that the cluster is reconciling towards.
	// If the cluster is not yet fully initialized desired will be set
	// with the information available, which may be an image or a tag.
	// +required
	Desired Release `json:"desired"`

So it may be still progressing, I guess.

[tchap]

I have to say I don't know exactly how this works, it's just based on the docs.