OCPBUGS-73855: Permit other machine managers when skew enforcement is in Automatic mode #2648

djoshy · 2026-01-14T16:53:25Z

While working on openshift/machine-config-operator#5539 and openshift/machine-config-operator#5428, I realized that the original skew validation rule should also permit MachineManagers of other types. This is because with openshift/machine-config-operator#5539, the MCO will respect a admin defined Manager opinion, and then merge into the status with OCP's default opinion for the other unspecified MachineManagers. For example, GCP by default looks like this:

apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
  name: cluster
  namespace: openshift-machine-config-operator
spec:
status:
  managedBootImagesStatus:
    machineManagers:
      - resource: controlplanemachinesets
        apiGroup: machine.openshift.io
        selection:
          mode: None
      - resource: machinesets
        apiGroup: machine.openshift.io
        selection:
          mode: All

If an admin then sets an opt-in config for the CPMS manager, the MCO will set the status as:

apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
  name: cluster
  namespace: openshift-machine-config-operator
spec:
  managedBootImages:
    machineManagers:
      - resource: controlplanemachinesets
        apiGroup: machine.openshift.io
        selection:
          mode: All
status:
  managedBootImagesStatus:
    machineManagers:
      - resource: controlplanemachinesets
        apiGroup: machine.openshift.io
        selection:
          mode: All
      - resource: machinesets
        apiGroup: machine.openshift.io
        selection:
          mode: All

Now, if we add Automatic skew mode to the mix, we run into an issue:

apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
  name: cluster
  namespace: openshift-machine-config-operator
spec:
status:
  managedBootImagesStatus:
    machineManagers:
      - resource: controlplanemachinesets
        apiGroup: machine.openshift.io
        selection:
          mode: None
      - resource: machinesets
        apiGroup: machine.openshift.io
        selection:
          mode: All
  bootImageSkewEnforcementStatus:
    mode: Automatic         
    automatic:
      ocpVersion: "4.18.2"
      rhcosVersion: "416.94.202411201433-0"

And then if we add a CPMS opinion, we would hope to see:

apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
  name: cluster
  namespace: openshift-machine-config-operator
spec:
  managedBootImages:
    machineManagers:
      - resource: controlplanemachinesets
        apiGroup: machine.openshift.io
        selection:
          mode: All
status:
  managedBootImagesStatus:
    machineManagers:
      - resource: controlplanemachinesets
        apiGroup: machine.openshift.io
        selection:
          mode: All
      - resource: machinesets
        apiGroup: machine.openshift.io
        selection:
          mode: All
  bootImageSkewEnforcementStatus:
    mode: Automatic         
    automatic:
      ocpVersion: "4.18.2"
      rhcosVersion: "416.94.202411201433-0"

Unfortunately due to the current validation rule for the spec field, this fails:

# machineconfigurations.operator.openshift.io "cluster" was not valid:
# * <nil>: Invalid value: "object": when skew enforcement is in Automatic mode, managedBootImages must contain a MachineManager opting in all MachineAPI MachineSets
#

We first noticed this on presubmit payload runs for CPMS tests: https://prow.ci.openshift.org/view/gs/test-platform-results/logs/openshift-machine-config-operator-5547-periodics-e2e-gcp-mco-disruptive-techpreview-1of2/2011125283620392960; they fail as the test is prevented by the validation from setting a CPMS configuration.

To fix this, I'm proposing that we break the old rule into two parts when skew enforcement is in Automatic mode:

If a MAPI MachineSet Manager is present in spec.managedBootImages.machineManagers, it must be set to All. A MAPI MachineSet Manager not being present is a valid state.
Guard against spec.managedBootImages.machineManagers to be defined as an empty list; this is an old way to opt the cluster out of boot image updates. When set, the MCO reflects an empty list to the status, and so this is something that we shouldn't permit while in Automatic mode. Alternatively, we could also consider always enforcing a length requirement if it is defined, regardless of skew enforcement mode.

I've also added tests for these validations targeting the BootImageSkewEnforcement and ManagedBootImagesCPMS feature gate. The validations for managedBootImagesStatus remains the same; the MCO should always ensure that there is an "All" MAPI MachineSet manager for platforms that support Automatic skew enforcement.

openshift-ci-robot · 2026-01-14T16:53:30Z

@djoshy: This pull request explicitly references no jira issue.

Details

In response to this:

While working on openshift/machine-config-operator#5539 and openshift/machine-config-operator#5428, I realized that the original skew validation rule should also permit MachineManagers of other types. This is because with openshift/machine-config-operator#5539, the MCO will respect a admin defined Manager opinion, and then merge into the status with OCP's default opinion for the other unspecified MachineManagers. For example, GCP by default looks like this:
apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
 name: cluster
 namespace: openshift-machine-config-operator
spec:
status:
 managedBootImagesStatus:
   machineManagers:
     - resource: controlplanemachinesets
       apiGroup: machine.openshift.io
       selection:
         mode: None
     - resource: machinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
If an admin then sets an opt-in config for the CPMS manager, the MCO will set the status as:
apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
 name: cluster
 namespace: openshift-machine-config-operator
spec:
 managedBootImages:
   machineManagers:
     - resource: controlplanemachinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
status:
 managedBootImagesStatus:
   machineManagers:
     - resource: controlplanemachinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
     - resource: machinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
Now, if we add Automatic skew mode to the mix, we run into an issue:
apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
 name: cluster
 namespace: openshift-machine-config-operator
spec:
status:
 managedBootImagesStatus:
   machineManagers:
     - resource: controlplanemachinesets
       apiGroup: machine.openshift.io
       selection:
         mode: None
     - resource: machinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
 bootImageSkewEnforcementStatus:
   mode: Automatic         
   automatic:
     ocpVersion: "4.18.2"
     rhcosVersion: "416.94.202411201433-0" 
And then if we add a CPMS opinion, we would hope to see:
apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
 name: cluster
 namespace: openshift-machine-config-operator
spec:
 managedBootImages:
   machineManagers:
     - resource: controlplanemachinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
status:
 managedBootImagesStatus:
   machineManagers:
     - resource: controlplanemachinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
     - resource: machinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
 bootImageSkewEnforcementStatus:
   mode: Automatic         
   automatic:
     ocpVersion: "4.18.2"
     rhcosVersion: "416.94.202411201433-0" 
Unfortunately due to the current validation rule for the spec field, this fails:
# machineconfigurations.operator.openshift.io "cluster" was not valid:
# * <nil>: Invalid value: "object": when skew enforcement is in Automatic mode, managedBootImages must contain a MachineManager opting in all MachineAPI MachineSets
#
We first noticed this on presubmit payload runs for CPMS tests: https://prow.ci.openshift.org/view/gs/test-platform-results/logs/openshift-machine-config-operator-5547-periodics-e2e-gcp-mco-disruptive-techpreview-1of2/2011125283620392960; they fail as the test is prevented by the validation from setting a CPMS configuration.

To fix this, I'm proposing that we break the old rule into two parts when skew enforcement is in Automatic mode:

If a MAPI MachineSet Manager is present in spec.managedBootImages.machineManagers, it must be set to All. A MAPI MachineSet Manager not being present is a valid state.

Guard against spec.managedBootImages.machineManagers to be defined as an empty list; this is an old way to opt the cluster out of boot image updates. When set, the MCO reflects an empty list to the status, and so this is something that we shouldn't permit while in Automatic mode. Alternatively, we could also consider always enforcing a length requirement if it is defined, regardless of skew enforcement mode.

I've also added tests for these validations targeting the BootImageSkewEnforcement and ManagedBootImagesCPMS feature gate. The validations for managedBootImagesStatus remains the same; the MCO should always ensure that there is an "All" MAPI MachineSet manager for platforms that support Automatic skew enforcement.

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.

openshift-ci · 2026-01-14T16:53:36Z

Hello @djoshy! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

coderabbitai · 2026-01-14T16:53:49Z

📝 Walkthrough

Walkthrough

This pull request modifies MachineConfiguration validation rules related to boot image skew enforcement. Changes include adding a new test file for ManagedBootImagesCPMS scenarios, updating error message expectations across existing test files, and refining validation logic in the Go type definitions and CRD manifests. The validation updates enforce that managedBootImages.machineManagers must be non-empty when in Automatic mode and require any MachineAPI MachineSet entry to use selection mode All under Automatic enforcement.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description is directly related to the changeset, providing detailed context on why the validation rule needed to be updated and explaining the specific scenarios where the old rule failed.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check	✅ Passed	The title clearly describes the main change: permitting other machine managers in Automatic mode skew enforcement, which directly aligns with the core validation logic update across all modified files.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

📝 Generate docstrings

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

openshift-ci-robot · 2026-01-14T16:54:20Z

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 · 2026-01-14T17:46:34Z

@djoshy: This PR was included in a payload test run from openshift/machine-config-operator#5428
trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command

periodic-ci-openshift-machine-config-operator-release-4.22-periodics-e2e-azure-mco-disruptive-techpreview-1of2

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/f4f58e50-f170-11f0-808e-83b6912e1c83-0

openshift-ci · 2026-01-14T17:46:51Z

@djoshy: This PR was included in a payload test run from openshift/machine-config-operator#5428
trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command

periodic-ci-openshift-machine-config-operator-release-4.22-periodics-e2e-azure-mco-disruptive-techpreview-2of2

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/ffbd1ba0-f170-11f0-89be-84f488d886ce-0

openshift-ci · 2026-01-14T17:47:39Z

@djoshy: This PR was included in a payload test run from openshift/machine-config-operator#5428
trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command

periodic-ci-openshift-machine-config-operator-release-4.22-periodics-e2e-gcp-mco-disruptive-techpreview-1of2

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/1c8b1200-f171-11f0-8878-79c2b5f63f90-0

openshift-ci · 2026-01-14T17:47:46Z

@djoshy: This PR was included in a payload test run from openshift/machine-config-operator#5428
trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command

periodic-ci-openshift-machine-config-operator-release-4.22-periodics-e2e-gcp-mco-disruptive-techpreview-2of2

See details on https://pr-payload-tests.ci.openshift.org/runs/ci/2091cd30-f171-11f0-862c-140aba58a64d-0

JoelSpeed

/lgtm

openshift-ci-robot · 2026-01-15T11:50:12Z

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aws-ovn
/test e2e-aws-ovn-hypershift
/test e2e-aws-ovn-hypershift-conformance
/test e2e-aws-ovn-techpreview
/test e2e-aws-serial-1of2
/test e2e-aws-serial-2of2
/test e2e-aws-serial-techpreview-1of2
/test e2e-aws-serial-techpreview-2of2
/test e2e-azure
/test e2e-gcp
/test e2e-upgrade
/test e2e-upgrade-out-of-change

openshift-ci · 2026-01-15T11:51:22Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JoelSpeed

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

~~OWNERS~~ [JoelSpeed]

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

djoshy · 2026-01-15T13:47:10Z

/retest-required

/verified by payload testing

openshift-ci-robot · 2026-01-15T13:47:23Z

@djoshy: This PR has been marked as verified by payload testing.

Details

In response to this:

/retest-required

/verified by payload testing

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.

djoshy · 2026-01-15T13:53:44Z

Hmm, the Azure payloads didn't launch due to an infra issue, but the original failures were only on platforms that already had boot images enabled by default(GCP, AWS) so it is not really relevant. For the GCP payload runs, the CPMS tests are now passing in a combined run with openshift/machine-config-operator#5428 (skew enforcement MVP PR) [1] [2]

openshift-ci-robot · 2026-01-15T15:01:53Z

/retest-required

Remaining retests: 0 against base HEAD 6ab113c and 2 for PR HEAD 844cfc0 in total

openshift-ci-robot · 2026-01-15T15:09:52Z

@djoshy: This pull request references Jira Issue OCPBUGS-73855, which is valid. The bug has been moved to the POST state.

3 validation(s) were run on this bug

bug is open, matching expected state (open)
bug target version (4.22.0) matches configured target version for branch (4.22.0)
bug is in the state New, which is one of the valid states (NEW, ASSIGNED, POST)

Requesting review from QA contact:
/cc @sergiordlr

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

Details

In response to this:

While working on openshift/machine-config-operator#5539 and openshift/machine-config-operator#5428, I realized that the original skew validation rule should also permit MachineManagers of other types. This is because with openshift/machine-config-operator#5539, the MCO will respect a admin defined Manager opinion, and then merge into the status with OCP's default opinion for the other unspecified MachineManagers. For example, GCP by default looks like this:
apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
 name: cluster
 namespace: openshift-machine-config-operator
spec:
status:
 managedBootImagesStatus:
   machineManagers:
     - resource: controlplanemachinesets
       apiGroup: machine.openshift.io
       selection:
         mode: None
     - resource: machinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
If an admin then sets an opt-in config for the CPMS manager, the MCO will set the status as:
apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
 name: cluster
 namespace: openshift-machine-config-operator
spec:
 managedBootImages:
   machineManagers:
     - resource: controlplanemachinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
status:
 managedBootImagesStatus:
   machineManagers:
     - resource: controlplanemachinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
     - resource: machinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
Now, if we add Automatic skew mode to the mix, we run into an issue:
apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
 name: cluster
 namespace: openshift-machine-config-operator
spec:
status:
 managedBootImagesStatus:
   machineManagers:
     - resource: controlplanemachinesets
       apiGroup: machine.openshift.io
       selection:
         mode: None
     - resource: machinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
 bootImageSkewEnforcementStatus:
   mode: Automatic         
   automatic:
     ocpVersion: "4.18.2"
     rhcosVersion: "416.94.202411201433-0" 
And then if we add a CPMS opinion, we would hope to see:
apiVersion: operator.openshift.io/v1
kind: MachineConfiguration
metadata:
 name: cluster
 namespace: openshift-machine-config-operator
spec:
 managedBootImages:
   machineManagers:
     - resource: controlplanemachinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
status:
 managedBootImagesStatus:
   machineManagers:
     - resource: controlplanemachinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
     - resource: machinesets
       apiGroup: machine.openshift.io
       selection:
         mode: All
 bootImageSkewEnforcementStatus:
   mode: Automatic         
   automatic:
     ocpVersion: "4.18.2"
     rhcosVersion: "416.94.202411201433-0" 
Unfortunately due to the current validation rule for the spec field, this fails:
# machineconfigurations.operator.openshift.io "cluster" was not valid:
# * <nil>: Invalid value: "object": when skew enforcement is in Automatic mode, managedBootImages must contain a MachineManager opting in all MachineAPI MachineSets
#
We first noticed this on presubmit payload runs for CPMS tests: https://prow.ci.openshift.org/view/gs/test-platform-results/logs/openshift-machine-config-operator-5547-periodics-e2e-gcp-mco-disruptive-techpreview-1of2/2011125283620392960; they fail as the test is prevented by the validation from setting a CPMS configuration.

To fix this, I'm proposing that we break the old rule into two parts when skew enforcement is in Automatic mode:

If a MAPI MachineSet Manager is present in spec.managedBootImages.machineManagers, it must be set to All. A MAPI MachineSet Manager not being present is a valid state.

Guard against spec.managedBootImages.machineManagers to be defined as an empty list; this is an old way to opt the cluster out of boot image updates. When set, the MCO reflects an empty list to the status, and so this is something that we shouldn't permit while in Automatic mode. Alternatively, we could also consider always enforcing a length requirement if it is defined, regardless of skew enforcement mode.

I've also added tests for these validations targeting the BootImageSkewEnforcement and ManagedBootImagesCPMS feature gate. The validations for managedBootImagesStatus remains the same; the MCO should always ensure that there is an "All" MAPI MachineSet manager for platforms that support Automatic skew enforcement.

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.

djoshy · 2026-01-15T16:23:39Z

/retest-required

djoshy added 2 commits January 14, 2026 11:37

machineconfiguration: update skew validation rule

58328a2

machineconfiguration: add skew x CPMS tests

844cfc0

openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jan 14, 2026

openshift-ci bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jan 14, 2026

openshift-ci bot requested review from JoelSpeed and everettraven January 14, 2026 16:54

djoshy mentioned this pull request Jan 14, 2026

MCO-1877: MCO-1879: MCO-1882: MCO-1884: Implement boot image skew enforcement MVP openshift/machine-config-operator#5428

Open

JoelSpeed reviewed Jan 15, 2026

View reviewed changes

openshift-ci bot assigned JoelSpeed Jan 15, 2026

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jan 15, 2026

openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 15, 2026

openshift-ci-robot added the verified Signifies that the PR passed pre-merge verification criteria label Jan 15, 2026

djoshy changed the title ~~NO-ISSUE: Permit other machine managers when skew enforcement is in Automatic mode~~ OCPBUGS-73855: Permit other machine managers when skew enforcement is in Automatic mode Jan 15, 2026

openshift-ci-robot added the jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. label Jan 15, 2026

openshift-ci bot requested a review from sergiordlr January 15, 2026 15:09

OCPBUGS-73855: Permit other machine managers when skew enforcement is in Automatic mode #2648

Are you sure you want to change the base?

OCPBUGS-73855: Permit other machine managers when skew enforcement is in Automatic mode #2648

Uh oh!

Conversation

djoshy commented Jan 14, 2026

Uh oh!

openshift-ci-robot commented Jan 14, 2026

Uh oh!

openshift-ci bot commented Jan 14, 2026

Uh oh!

coderabbitai bot commented Jan 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Uh oh!

openshift-ci-robot commented Jan 14, 2026

Uh oh!

openshift-ci bot commented Jan 14, 2026

Uh oh!

openshift-ci bot commented Jan 14, 2026

Uh oh!

openshift-ci bot commented Jan 14, 2026

Uh oh!

openshift-ci bot commented Jan 14, 2026

Uh oh!

JoelSpeed left a comment

Choose a reason for hiding this comment

Uh oh!

openshift-ci-robot commented Jan 15, 2026

Uh oh!

openshift-ci bot commented Jan 15, 2026

Uh oh!

djoshy commented Jan 15, 2026

Uh oh!

openshift-ci-robot commented Jan 15, 2026

Uh oh!

djoshy commented Jan 15, 2026

Uh oh!

openshift-ci-robot commented Jan 15, 2026

Uh oh!

openshift-ci-robot commented Jan 15, 2026

Uh oh!

djoshy commented Jan 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

coderabbitai bot commented Jan 14, 2026 •

edited

Loading