OKD: Bump openshift/api to enable CPMS boot image support

[Prashanth684]

Updates openshift/api to include ManagedBootImagesCPMS feature gate promotion to Default/OKD featuresets. Fixes 4.21->4.22 upgrade validation error for controlplanemachinesets.

I0206 14:50:12.201490       1 event.go:377] Event(v1.ObjectReference{Kind:"", Namespace:"openshift-machine-config-operator", Name:"machine-config", UID:"6536a1f7-2bde-4230-b73e-751bb135e609", APIVersion:"", ResourceVersion:"", FieldPath:""}): type: 'Warning' reason: 'OperatorDegraded: MachineConfigurationFailed' Failed to resync 4.22.0-0.okd-scos-nightly-2026-02-06-104857 because: error updating MachineConfiguration status: MachineConfiguration.operator.openshift.io "cluster" is invalid: [status.managedBootImagesStatus.machineManagers[1].resource: Unsupported value: "controlplanemachinesets": supported values: "machinesets", <nil>: Invalid value: null: some validation rules were not checked because the object was invalid; correct the existing errors to complete validation]

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Prashanth684
Once this PR has been reviewed and has the lgtm label, please assign dkhater-redhat 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:

• OWNERS

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

[djoshy]

Does this block the upgrade and would this really fix the event not showing up? This seems like a CRD update hadn't happened during the upgrade while the new MCO was rolling out. It should eventually clear up, but not sure how bumping the API does anything; the CRD(and feature promo is via cluster config) is not pushed by the MCO.

[Prashanth684]

Does this block the upgrade and would this really fix the event not showing up? This seems like a CRD update hadn't happened during the upgrade while the new MCO was rolling out. It should eventually clear up, but not sure how bumping the API does anything; the CRD(and feature promo is via cluster config) is not pushed by the MCO.

right...so my assumption was this was a race where MCO started before the CRDs were updated and it was happening because of that. It does eventually clear up though

[Prashanth684]

Does this block the upgrade and would this really fix the event not showing up? This seems like a CRD update hadn't happened during the upgrade while the new MCO was rolling out. It should eventually clear up, but not sure how bumping the API does anything; the CRD(and feature promo is via cluster config) is not pushed by the MCO.

right...so my assumption was this was a race where MCO started before the CRDs were updated and it was happening because of that. It does eventually clear up though

hm...actually if there is a race, this might make it worse

[Prashanth684]

Does this block the upgrade and would this really fix the event not showing up? This seems like a CRD update hadn't happened during the upgrade while the new MCO was rolling out. It should eventually clear up, but not sure how bumping the API does anything; the CRD(and feature promo is via cluster config) is not pushed by the MCO.

right...so my assumption was this was a race where MCO started before the CRDs were updated and it was happening because of that. It does eventually clear up though

hm...actually if there is a race, this might make it worse

this is happening consistently for OKD - this is an example and it's causing upgrade job failures

[djoshy]

IMO, this PR won't have any effect on behavior, it is a race condition between the time APIServer recognizes the updated CRD and when the MCO begins to act on it. The MCO isn't in control of applying the new CRD and bumping MCO API vendor will not speed it up(the CVO is and it obtains the CRDs from o/api). The run levels for the CRD is earlier than the MCO deployment, so the MCO CRDs should be in place before the new deployment takes action.

It is probably worth asking in API forum or consulting CVO folks as to how to best approach this.

[openshift-ci]

@Prashanth684: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-hypershift	a0b898b	link	true	/test e2e-hypershift

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

[djoshy]

/close

resolved via slack discussion

[djoshy]

/close

[openshift-ci]

@djoshy: Closed this PR.

Details

In response to this:

/close

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.