MCO-1669: add BootImageSkewEnforcement API #2357

djoshy · 2025-06-05T16:50:28Z

Install time workflow, active for release (n-1) and above

flowchart TD
    A[MCO install-time check] --> B{Is the skew API spec set?}   
    B --> |No|C{Can the MCO manage boot images for this cluster?}
    B --> |Yes|E[Done]   
    C --> |No|D[Set skew API spec to Manual, with boot image matching install time values]
    C --> |Yes|E
    D --> E

Reconciliation flow for skew API fields, active for upgrades to release (n-1) & above

flowchart TD
    A[Operator sync loop] --> B{Is the skew API spec/status set?}   
    B --> |No|C{Can the MCO manage boot images for this cluster?}
    B --> |Yes|E[Done]   
    C --> |No|D[Set Upgradeable=False to force cluster admin opinion]
    C --> |Yes|F[Set skew API status to Automatic]
    D --> E
    F --> E

Skew enforcement mechanism sync loop, active in release n

flowchart TD
    A[Sync loop for skew mechanism. Triggered on: skew API knob updates, boot image update conditions] --> U{Is skew API mode set?}   
    U --> |Yes|V{Determine skew API mode: Automatic, Manual or None?}
    U --> |No|K
    V --> |None|L[Raise a low level Prometheus alert to indicate scaling risk]
    V --> |Manual|I 
    V --> |Automatic|E{Is the boot image controller in an error mode?}
    E --> |No| H[Wait until boot image controller is not progressing]
    E --> |Yes| K
    H --> I[Is the current skew compliant against the limit defined in the release image?]   
    I --> |Yes| Done
    I --> |No| K[MCO sets Upgradeable=False] 
    K --> Done
    L --> Done

Validation Tables

Both Spec Fields Set

ManagedBootImages spec	SkewEnforcement spec	ManagedBootImages status	SkewEnforcement status	Action
All	Manual	(ignored)	(ignored)	Good
All	None	(ignored)	(ignored)	Good
Partial	Manual	(ignored)	(ignored)	Good
Partial	None	(ignored)	(ignored)	Good
None	Manual	(ignored)	(ignored)	Good
None	None	(ignored)	(ignored)	Good

Only ManagedBootImages Empty

ManagedBootImages spec	SkewEnforcement spec	ManagedBootImages status	SkewEnforcement status	Action
Empty	Manual	All	(ignored)	Good
Empty	None	All	(ignored)	Good
Empty	Manual	Partial	(ignored)	Good
Empty	None	Partial	(ignored)	Good
Empty	Manual	None	(ignored)	Good
Empty	None	None	(ignored)	Good
Empty	Manual	Empty	(ignored)	Good
Empty	None	Empty	(ignored)	Good

Only SkewEnforcement Empty

ManagedBootImages spec	SkewEnforcement spec	ManagedBootImages status	SkewEnforcement status	Action
All	Empty	(ignored)	Automatic	Good
All	Empty	(ignored)	Empty	Controller error
Partial	Empty	(ignored)	Automatic	API validation failure
Partial	Empty	(ignored)	Empty	Good
None	Empty	(ignored)	Automatic	API validation failure
None	Empty	(ignored)	Empty	Good

Both Spec Fields Empty

ManagedBootImages spec	SkewEnforcement spec	ManagedBootImages status	SkewEnforcement status	Action
Empty	Empty	All	Automatic	Good
Empty	Empty	All	Empty	Controller error
Empty	Empty	Partial	Automatic	API validation failure
Empty	Empty	Partial	Empty	Good
Empty	Empty	None	Automatic	API validation failure
Empty	Empty	None	Empty	Good
Empty	Empty	Empty	Automatic	API validation failure
Empty	Empty	Empty	Empty	Good

openshift-ci-robot · 2025-06-05T16:50:32Z

@djoshy: This pull request references MCO-1669 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set.

In response to this:

WIP boot image enforcement API, based on discussions from openshift/enhancements#1761

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 · 2025-06-05T16:50:33Z

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.

operator/v1/types_machineconfiguration.go

djoshy · 2025-07-14T20:21:59Z

Thanks for the questions & review(sorry it took a while!), this should be ready for another look. Happy to hop on a call if that is easier.

Update: Did another push to fix up some tests.

everettraven

Leaving another handful of comments.

I'm also happy to hop on a call if you think it would be beneficial.

operator/v1/types_machineconfiguration.go

everettraven

A few minor comments, but other than these I think this looks good

operator/v1/types_machineconfiguration.go

operator/v1/tests/machineconfigurations.operator.openshift.io/BootImageSkewEnforcement.yaml

yuqi-zhang

A couple of maybe dumb questions:

operator/v1/types_machineconfiguration.go

openshift-ci-robot · 2025-08-07T15:07:32Z

@djoshy: This pull request references MCO-1669 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set.

In response to this:

Based on discussions from openshift/enhancements#1761
Proposed workflow:

flowchart TD
   A[Sync loop for skew mechanism. Triggered on: skew API knob updates, boot image update conditions] --> U{Is Skew API knob defined for this cluster?}    
   U --> |Yes| V{Determine skew API mode: Automatic, Manual or None?}
   V --> |None|J
   V --> |Manual|I 
   V --> |Automatic|E
   U --> |No| B{Can the MCO manage boot images for this cluster?}
   B --> |Yes| C[Skew API knob set to automatic]
   B --> |No| D[Skew API knob set to manual, cluster boot image estimated from cluster defaults]
   C --> E{Is the boot image controller disabled or in an error mode?}
   E --> |No| H[Wait until boot image controller is not progressing]
   E --> |Yes| G[Throw an error to cluster admin]
   G --> Done
   D --> I
   H --> I[Is skew compliant against the current release image?]   
   I --> |No| K[Set CO upgradeable=false] 
   I --> |Yes| Done
   K --> J[Disable scaling via MCS rejects & RHCOS templates]
   J --> Done

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-robot · 2025-08-07T15:13:22Z

@djoshy: This pull request references MCO-1669 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set.

In response to this:

Based on discussions from openshift/enhancements#1761
Proposed workflow:

flowchart TD
   A[Sync loop for skew mechanism. Triggered on: skew API knob updates, boot image update conditions] --> U{Is Skew API knob defined for this cluster?}    
   U --> |Yes| V{Determine skew API mode: Automatic, Manual or None?}
   V --> |None|J
   V --> |Manual|I 
   V --> |Automatic|E
   U --> |No| B{Can the MCO manage boot images for this cluster?}
   B --> |Yes| C[Skew API knob set to automatic]
   B --> |No| D[Skew API knob set to manual, cluster boot image estimated from cluster version]
   C --> E{Is the boot image controller disabled or in an error mode?}
   E --> |No| H[Wait until boot image controller is not progressing]
   E --> |Yes| G[Throw an error to cluster admin]
   G --> Done
   D --> I
   H --> I[Is skew compliant against the current release image?]   
   I --> |No| K[Set CO upgradeable=false] 
   I --> |Yes| Done
   K --> J[Disable scaling via MCS rejects & RHCOS templates]
   J --> Done

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-robot · 2025-08-07T18:57:50Z

@djoshy: This pull request references MCO-1669 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set.

In response to this:

Based on discussions from openshift/enhancements#1761:
Workflow for release (n-1)

flowchart TD
   A[Operator sync loop] --> B{Is the skew API spec/status set?}   
   B --> |No|C{Can the MCO manage boot images for this cluster?}
   B --> |Yes|E[Done]   
   C --> |No|D[Set Upgradeable=False to warn cluster admin]
   C --> |Yes|F[Set skew AI status to Automatic]
   D --> E
   F --> E

Workflow for release n

flowchart TD
   A[Sync loop for skew mechanism. Triggered on: skew API knob updates, boot image update conditions] --> V{Determine skew API mode: Automatic, Manual or None?}   
   V --> |None|L[Raise a low level Prometheus alert to indicate scaling risk]
   V --> |Manual|I 
   V --> |Automatic|E{Is the boot image controller disabled or in an error mode?}
   E --> |No| H[Wait until boot image controller is not progressing]
   E --> |Yes| G[Throw an error to cluster admin]
   G --> K
   H --> I[Is the current skew compliant against the limit defined in the release image?]   
   I --> |Yes| Done
   I --> |No| K[MCO degrades the cluster] 
   K --> Done
   L --> Done

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-robot · 2025-08-11T19:55:05Z

@djoshy: This pull request references MCO-1669 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set.

In response to this:

Based on discussions from openshift/enhancements#1761:
Workflow for pre-release skew enforcement not active

flowchart TD
   A[Operator sync loop] --> B{Is the skew API spec/status set?}   
   B --> |No|C{Can the MCO manage boot images for this cluster?}
   B --> |Yes|E[Done]   
   C --> |No|D[Set Upgradeable=False to force cluster admin opinion]
   C --> |Yes|F[Set skew API status to Automatic]
   D --> E
   F --> E

Workflow for release n, skew enforcement is active

flowchart TD
   A[Sync loop for skew mechanism. Triggered on: skew API knob updates, boot image update conditions] --> V{Determine skew API mode: Automatic, Manual or None?}   
   V --> |None|L[Raise a low level Prometheus alert to indicate scaling risk]
   V --> |Manual|I 
   V --> |Automatic|E{Is the boot image controller disabled or in an error mode?}
   E --> |No| H[Wait until boot image controller is not progressing]
   E --> |Yes| G[Throw an error to cluster admin]
   G --> K
   H --> I[Is the current skew compliant against the limit defined in the release image?]   
   I --> |Yes| Done
   I --> |No| K[MCO sets Upgradeable=False] 
   K --> Done
   L --> Done

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 · 2025-08-15T19:11:25Z

Last push includes:

removed Automatic enum value from the spec
updated the go doc to account for our recent discussions about Manual mode, and how the user is required to set a value to allow upgrades for certain cases.
accounted for new linter rules

It seems to be failing NoNewRequiredFields in verify, which must be a recent change. Is it okay to not have a required tag for a union discriminators like Mode?

everettraven · 2025-08-20T19:55:10Z

Last push includes:

removed Automatic enum value from the spec

updated the go doc to account for our recent discussions about Manual mode, and how the user is required to set a value to allow upgrades for certain cases.

accounted for new linter rules

It seems to be failing NoNewRequiredFields in verify, which must be a recent change. Is it okay to not have a required tag for a union discriminators like Mode?

@djoshy The NoNewRequiredFields isn't new from what I recall, but it is actually a bit buggy and picks up required children fields in a new optional parent field - which is OK. That appears to be what is happening in this case so we can override the check when we are ready for this to merge (overriding it now won't do any good as other things will likely merge in the meantime and re-trigger testing).

everettraven

Took another look at this and from what I recall this aligns with what was discussed synchronously. I'm going to circle back around to see if there are any outstanding comments left from Joel's previous review while I was out, but otherwise this direction looks good to me.

openshift-ci-robot · 2025-09-16T20:04:21Z

@djoshy: This pull request references MCO-1669 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.21.0" version, but no target version was set.

In response to this:

Install time workflow, active for release (n-1) and above

flowchart TD
   A[MCO install-time check] --> B{Is the skew API spec set?}   
   B --> |No|C{Can the MCO manage boot images for this cluster?}
   B --> |Yes|E[Done]   
   C --> |No|D[Set skew API spec to Manual, with boot image matching install time values]
   C --> |Yes|E
   D --> E

Reconciliation flow for skew API fields, active for upgrades to release (n-1) & above

flowchart TD
   A[Operator sync loop] --> B{Is the skew API spec/status set?}   
   B --> |No|C{Can the MCO manage boot images for this cluster?}
   B --> |Yes|E[Done]   
   C --> |No|D[Set Upgradeable=False to force cluster admin opinion]
   C --> |Yes|F[Set skew API status to Automatic]
   D --> E
   F --> E

Skew enforcement mechanism sync loop, active in release n

flowchart TD
   A[Sync loop for skew mechanism. Triggered on: skew API knob updates, boot image update conditions] --> U{Is skew API mode set?}   
   U --> |Yes|V{Determine skew API mode: Automatic, Manual or None?}
   U --> |No|K
   V --> |None|L[Raise a low level Prometheus alert to indicate scaling risk]
   V --> |Manual|I 
   V --> |Automatic|E{Is the boot image controller in an error mode?}
   E --> |No| H[Wait until boot image controller is not progressing]
   E --> |Yes| K
   H --> I[Is the current skew compliant against the limit defined in the release image?]   
   I --> |Yes| Done
   I --> |No| K[MCO sets Upgradeable=False] 
   K --> Done
   L --> Done

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-robot · 2025-09-16T20:16:26Z

@djoshy: This pull request references MCO-1669 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.21.0" version, but no target version was set.

In response to this:

Install time workflow, active for release (n-1) and above
flowchart TD
   A[MCO install-time check] --> B{Is the skew API spec set?}   
   B --> |No|C{Can the MCO manage boot images for this cluster?}
   B --> |Yes|E[Done]   
   C --> |No|D[Set skew API spec to Manual, with boot image matching install time values]
   C --> |Yes|E
   D --> E
Loading
Reconciliation flow for skew API fields, active for upgrades to release (n-1) & above
flowchart TD
   A[Operator sync loop] --> B{Is the skew API spec/status set?}   
   B --> |No|C{Can the MCO manage boot images for this cluster?}
   B --> |Yes|E[Done]   
   C --> |No|D[Set Upgradeable=False to force cluster admin opinion]
   C --> |Yes|F[Set skew API status to Automatic]
   D --> E
   F --> E
Loading
Skew enforcement mechanism sync loop, active in release n
flowchart TD
   A[Sync loop for skew mechanism. Triggered on: skew API knob updates, boot image update conditions] --> U{Is skew API mode set?}   
   U --> |Yes|V{Determine skew API mode: Automatic, Manual or None?}
   U --> |No|K
   V --> |None|L[Raise a low level Prometheus alert to indicate scaling risk]
   V --> |Manual|I 
   V --> |Automatic|E{Is the boot image controller in an error mode?}
   E --> |No| H[Wait until boot image controller is not progressing]
   E --> |Yes| K
   H --> I[Is the current skew compliant against the limit defined in the release image?]   
   I --> |Yes| Done
   I --> |No| K[MCO sets Upgradeable=False] 
   K --> Done
   L --> Done
Loading
Validation Tables

Both Spec Fields Set

ManagedBootImages spec SkewEnforcement spec ManagedBootImages status SkewEnforcement status Action

All Manual (ignored) (ignored) Good

All None (ignored) (ignored) Good

Partial Manual (ignored) (ignored) Good

Partial None (ignored) (ignored) Good

None Manual (ignored) (ignored) Good

None None (ignored) (ignored) Good

Only ManagedBootImages Empty

ManagedBootImages spec SkewEnforcement spec ManagedBootImages status SkewEnforcement status Action

Empty Manual All (ignored) Good

Empty None All (ignored) Good

Empty Manual Partial (ignored) Good

Empty None Partial (ignored) Good

Empty Manual None (ignored) Good

Empty None None (ignored) Good

Empty Manual Empty (ignored) Good

Empty None Empty (ignored) Good

Only SkewEnforcement Empty

ManagedBootImages spec SkewEnforcement spec ManagedBootImages status SkewEnforcement status Action

All Empty (ignored) Automatic Good

All Empty (ignored) Empty Controller error

Partial Empty (ignored) Automatic API validation failure

Partial Empty (ignored) Empty Good

None Empty (ignored) Automatic API validation failure

None Empty (ignored) Empty Good

Both Spec Fields Empty

ManagedBootImages spec SkewEnforcement spec ManagedBootImages status SkewEnforcement status Action

Empty Empty All Automatic Good

Empty Empty All Empty Controller error

Empty Empty Partial Automatic API validation failure

Empty Empty Partial Empty Good

Empty Empty None Automatic API validation failure

Empty Empty None Empty Good

Empty Empty Empty Automatic API validation failure

Empty Empty Empty Empty Good

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 · 2025-09-16T20:18:36Z

/test all

I think we're good to go here, I've updated the flowcharts and added the validation tables to the description per our latest discussions. cc @yuqi-zhang @everettraven Care to take a last look?

everettraven

A handful of minor comments, but other than these the API changes and proposed flow LGTM

operator/v1/types_machineconfiguration.go

JoelSpeed · 2025-09-17T16:01:24Z

operator/v1/types_machineconfiguration.go

+	// manual describes the current boot image of the cluster.
+	// This should be set to the oldest boot image used amongst all machine resources in the cluster.
+	// This includes the RHCOS version of the boot image and the OCP release version which shipped with that RHCOS boot image.
+	// If ocpVersion and rhcosVersion are defined, both values will be used for checking skew compliance.


I assume the lower value (older image?) will be the authority? When does it make sense for both of these to be set? Should we enforce a single value only?

I assume the lower value (older image?) will be the authority?

Our initial thought was an AND check if they're both defined, but its not a strongly held opinion by any means.

When does it make sense for both of these to be set? Should we enforce a single value only? When does it make sense for both of these to be set?

In Manual mode, where the admin sets these values, requiring only one of them felt a bit more convenient in terms of UX.

In Automatic mode, the MCO's controller would be able to set both. I think we figured more diagnostic information, if possible, was better.

I suppose, if we think its a bit superfluous/problematic, we could potentially tighten up the validation later? 🤔

So I think an AND check means the oldest image is the one the skew comes from

I guess it's hard to define what the right thing to do here is, but if you think in automatic mode there's value in setting both, I can see that making sense

We could add a validation so that in Manual mode, only one choice can be made (in spec?) to prevent us having to make a choice

Starting to feel like the manual spec config should be a discriminated union 🤔

No strong opinion on this, but as David said, I think this was here mostly for ease of use for different admins, and in that sense, there shouldn't be a reason for them to set both RHCOS and OCP versions. I'd be +1 on Joel's last suggestion around enforcing that in manual mode, you can only set one or the other.

New union looks correct to me, thanks

Updated status side + tests too, let me know how that looks! I tried my best to align the go-docs, hope I didn't miss anything 😅

Maybe I'm missing it, but I don't see the tests added for the manual modes in the status specifically.

I know it may seem redundant, but I'd personally like to have explicit tests for the union behavior in both spec and status to ensure we don't inadvertently break any expectations here in the future.

ack, sorry about that, just added it - let me know if that's sufficient. Also fixed the typo that Joel had mentioned on slack in the new union discriminator's godoc.

argh, found another typo, fixing and pushing up shortly 😅

Update: should be ready now

everettraven

Another couple minor typos (old field names most likely)

everettraven · 2025-09-19T18:14:25Z

operator/v1/types_machineconfiguration.go

+	// This field must match the OCP semver compatible format of x.y.z. This field must be between
+	// 5 and 10 characters long.
+	// Required when mode is set to "OCPVersion" and forbidden otherwise.
+	// +kubebuilder:validation:XValidation:rule="self.matches('^[0-9]+\\\\.[0-9]+\\\\.[0-9]+$')",message="bootImageOCPVersion must match the OCP semver compatible format of x.y.z"


Suggested change

// +kubebuilder:validation:XValidation:rule="self.matches('^[0-9]+\\\\.[0-9]+\\\\.[0-9]+$')",message="bootImageOCPVersion must match the OCP semver compatible format of x.y.z"

// +kubebuilder:validation:XValidation:rule="self.matches('^[0-9]+\\\\.[0-9]+\\\\.[0-9]+$')",message="ocpVersion must match the OCP semver compatible format of x.y.z"

Fixed, thanks! And added a test since I realized we didn't have them for this error mode.

operator/v1/types_machineconfiguration.go

everettraven

/lgtm

openshift-ci-robot · 2025-09-19T20:55:38Z

/test remaining-required

Scheduling tests matching the pipeline_run_if_changed parameter:
/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 · 2025-09-19T20:56:02Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: everettraven, JoelSpeed

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

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [JoelSpeed,everettraven]

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

everettraven · 2025-09-19T20:56:09Z

@djoshy I'll leave it up to you how you would like to get this change verified and add the verified label.

djoshy · 2025-09-22T13:03:42Z

/verified later

We'll verify this later alongside the MCO PoC PR.

openshift-ci-robot · 2025-09-22T13:04:01Z

@djoshy: Only users can be targets for the /verified later command.

In response to this:

/verified later

We'll verify this later alongside the MCO PoC PR.

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 · 2025-09-22T13:04:13Z

/verified later @ptalgulk01

openshift-ci-robot · 2025-09-22T13:04:27Z

@djoshy: This PR has been marked to be verified later by @ptalgulk01.

In response to this:

/verified later @ptalgulk01

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 · 2025-09-22T16:09:18Z

@djoshy: all tests passed!

Full PR test history. Your PR dashboard.

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.

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

openshift-ci bot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. labels Jun 5, 2025

openshift-ci bot requested review from deads2k and everettraven June 5, 2025 16:51

djoshy mentioned this pull request Jun 5, 2025

MCO-1504: Update bootimage management enhancement openshift/enhancements#1761

Merged

everettraven reviewed Jun 17, 2025

View reviewed changes

djoshy force-pushed the skew-enforcement branch from eee6809 to 54938cf Compare July 14, 2025 20:21

djoshy force-pushed the skew-enforcement branch from 54938cf to 0344f1e Compare July 15, 2025 14:58

everettraven reviewed Jul 15, 2025

View reviewed changes

djoshy force-pushed the skew-enforcement branch from 0344f1e to 5816e99 Compare July 17, 2025 18:46

everettraven reviewed Jul 22, 2025

View reviewed changes

djoshy force-pushed the skew-enforcement branch from 5816e99 to ac57873 Compare July 23, 2025 20:26

yuqi-zhang reviewed Jul 28, 2025

View reviewed changes

operator/v1/types_machineconfiguration.go Outdated Show resolved Hide resolved

operator/v1/types_machineconfiguration.go Show resolved Hide resolved

djoshy force-pushed the skew-enforcement branch from ac57873 to 66a9ee8 Compare July 30, 2025 13:04

JoelSpeed reviewed Aug 6, 2025

View reviewed changes

openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 11, 2025

djoshy force-pushed the skew-enforcement branch from 66a9ee8 to ced817a Compare August 15, 2025 18:02

openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 15, 2025

djoshy force-pushed the skew-enforcement branch from ced817a to 8181cc5 Compare August 15, 2025 19:06

everettraven reviewed Aug 20, 2025

View reviewed changes

everettraven reviewed Sep 17, 2025

View reviewed changes

djoshy force-pushed the skew-enforcement branch from 04f36b6 to 7087c1e Compare September 17, 2025 14:39

JoelSpeed reviewed Sep 17, 2025

View reviewed changes

djoshy added 2 commits September 18, 2025 16:44

machine_config: add BootImageSkewEnforcement API

de95768

cross-validate boot images & skew enforcement

bcad208

djoshy force-pushed the skew-enforcement branch 4 times, most recently from b7878f2 to 9657bc1 Compare September 19, 2025 17:19

everettraven reviewed Sep 19, 2025

View reviewed changes

add union discriminator for manual mode

08bfa12

djoshy force-pushed the skew-enforcement branch from 9657bc1 to 08bfa12 Compare September 19, 2025 19:20

everettraven approved these changes Sep 19, 2025

View reviewed changes

openshift-ci bot assigned everettraven Sep 19, 2025

openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Sep 19, 2025

openshift-ci-robot added verified-later verified Signifies that the PR passed pre-merge verification criteria labels Sep 22, 2025

openshift-merge-bot bot merged commit 04f99ea into openshift:master Sep 22, 2025
28 checks passed

djoshy mentioned this pull request Sep 22, 2025

MCO-1669: Bump o/api for skew enforcement API openshift/client-go#338

Merged

	// +kubebuilder:validation:XValidation:rule="self.matches('^[0-9]+\\\\.[0-9]+\\\\.[0-9]+$')",message="bootImageOCPVersion must match the OCP semver compatible format of x.y.z"
	// +kubebuilder:validation:XValidation:rule="self.matches('^[0-9]+\\\\.[0-9]+\\\\.[0-9]+$')",message="ocpVersion must match the OCP semver compatible format of x.y.z"

MCO-1669: add BootImageSkewEnforcement API #2357

MCO-1669: add BootImageSkewEnforcement API #2357

Uh oh!

Conversation

djoshy commented Jun 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Install time workflow, active for release (n-1) and above

Reconciliation flow for skew API fields, active for upgrades to release (n-1) & above

Skew enforcement mechanism sync loop, active in release n

Validation Tables

Both Spec Fields Set

Only ManagedBootImages Empty

Only SkewEnforcement Empty

Both Spec Fields Empty

Uh oh!

openshift-ci-robot commented Jun 5, 2025 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci bot commented Jun 5, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

djoshy commented Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

everettraven left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

everettraven left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

yuqi-zhang left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

openshift-ci-robot commented Aug 7, 2025 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Aug 7, 2025 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Aug 7, 2025 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

openshift-ci-robot commented Aug 11, 2025 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

djoshy commented Aug 15, 2025

Uh oh!

everettraven commented Aug 20, 2025

Uh oh!

everettraven left a comment

Choose a reason for hiding this comment

Uh oh!

openshift-ci-robot commented Sep 16, 2025 • edited by openshift-ci bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Install time workflow, active for release (n-1) and above

djoshy commented Jun 5, 2025 •

edited

Loading

openshift-ci-robot commented Jun 5, 2025 •

edited by openshift-ci bot

Loading

djoshy commented Jul 14, 2025 •

edited

Loading

openshift-ci-robot commented Aug 7, 2025 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Aug 7, 2025 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Aug 7, 2025 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Aug 11, 2025 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Sep 16, 2025 •

edited by openshift-ci bot

Loading

openshift-ci-robot commented Sep 16, 2025 •

edited by openshift-ci bot

Loading

djoshy Sep 17, 2025 •

edited

Loading

djoshy Sep 19, 2025 •

edited

Loading

djoshy Sep 19, 2025 •

edited

Loading