MCO-2151: Add stream detection to the boot image controller

[djoshy]

- What I did
Added stream label detection for the boot image controller. If no label is found, it is considered an older pre "dual stream" machineset/controlplanemachineset and is updated for backwards compatibility. If a label is found, it is checked against the currently supported stream in the boot image controller, and then reconciled if it is a match.

I also took this opportunity to clean up a couple of unrelated logs/comments.

- How to verify it
All existing bootimage e2es should pass.

1. Create a GCP/AWS/Azure/Vsphere cluster
2. Label one of the machinesets to indicate the rhel-10 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-10

For bonus points, you could use a rhel-10 boot image for AWS/GCP from here. Adding a rhel-10 bootimage for Azure/vSphere is slightly more involved than editing in a reference, but should work as well. This is not strictly required since this code is platform agnostic.

3. This should trigger a reconciliation loop in the boot image controller. Examine the controller logs, it should state that the update was skipped.

ms_helpers.go:126] machineset ci-ln-97wxgxb-72292-bg8vs-worker-b has unsupported stream: rhel-10, skipping boot image update

4. Now, label the machineset to indicate the rhel-9 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-9

Note: On AWS, if you've used a rhel-10 AMI in step (2), set it back to any rhel-9 AMI. This is because the boot image controller uses a whitelist for updates and the rhel-10 AMI wouldn't be in the whitelist; resulting in a skipped update.

5. This should trigger a reconciliation loop and the machineset should now be set to a rhel-9 bootimage defined by rhcos.json.

Summary by CodeRabbit

• New Features
  • Boot image management now recognizes and respects OS stream labels, enabling support for distinct OS streams (including RHEL-9).
  • Boot image updates will automatically skip Windows systems and machines labeled for unsupported/non-default OS streams to avoid incompatible changes.

[openshift-ci-robot]

@djoshy: This pull request references MCO-2151 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.22.0" version, but no target version was set.

Details

In response to this:

- What I did
Added stream label detection for the boot image controller. If no label is found, it is considered an older pre "dual stream" machineset and is updated for backwards compatibility. If a label is found, it is checked against the currently supported stream in the boot image controller, and updated if it is a match.

I also took this opportunity to clean up a couple of unrelated comments.

- How to verify it
All existing bootimage e2es should pass.

1. Create a GCP/AWS/Azure/Vsphere cluster
2. Label one of the machinesets to indicate the rhel-10 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-10

For bonus points, you could use a rhel-10 boot image for AWS/GCP from here. Adding a rhel-10 bootimage for Azure/vSphere is slightly more involved than editing in a reference, but should work as well. This is not strictly required since this code is platform agnostic.

3. This should trigger a reconciliation loop in the boot image controller. Examine the controller logs, it should state that the update was skipped.
4. Now, label the machineset to indicate the rhel-9 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-9

Note: On AWS, if you've used a rhel-10 AMI in step (2), set it back to any rhel-9 AMI. This is because the boot image controller uses a whitelist for updates and the rhel-10 AMI wouldn't be in the whitelist; resulting in a skipped update.

5. This should trigger a reconciliation loop and the machineset should now be set to a rhel-9 bootimage defined by rhcos.json.

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]

Walkthrough

Adds two public constants for OS stream labeling and inserts pre-checks in boot image controller helpers to short-circuit reconciliation for machinesets/control-plane machinesets that specify a non-supported OS stream or are Windows-labelled, before fetching cluster/infra/bootimage config.

Changes

Cohort / File(s)	Summary
Boot Image Controller Constants pkg/controller/bootimage/boot_image_controller.go	Added two public constants: OSStreamLabelKey ("machineconfiguration.openshift.io/osstream") and SupportedOSStream ("rhel-9").
MachineSet Helpers pkg/controller/bootimage/ms_helpers.go	In syncMAPIMachineSet, added pre-checks to skip processing when a MachineSet has an OS stream label not equal to SupportedOSStream or when the MachineSet template OS label indicates Windows; these skips return early (not counted as skipped) before fetching cluster version, infra, or boot image config. Minor log/comment wording updates and owner-ref log uses MS name.
ControlPlaneMachineSet Helpers pkg/controller/bootimage/cpms_helpers.go	Added equivalent guards to skip reconciliation for ControlPlaneMachineSets with a non-default OS stream label or Windows OS label; owner-reference handling now logs using the CPMS name. No public API changes.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: adding stream detection to the boot image controller, which is the primary focus of all three modified files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Stable And Deterministic Test Names	✅ Passed	This PR does not modify any Ginkgo test files. All changes are to implementation files only.
Test Structure And Quality	✅ Passed	The custom check requires reviewing Ginkgo test code for quality requirements, but this PR does not modify any test files—only three controller implementation files.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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

[openshift-ci-robot]

@djoshy: This pull request references MCO-2151 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.22.0" version, but no target version was set.

Details

In response to this:

- What I did
Added stream label detection for the boot image controller. If no label is found, it is considered an older pre "dual stream" machineset and is updated for backwards compatibility. If a label is found, it is checked against the currently supported stream in the boot image controller, and updated if it is a match.

I also took this opportunity to clean up a couple of unrelated comments.

- How to verify it
All existing bootimage e2es should pass.

1. Create a GCP/AWS/Azure/Vsphere cluster
2. Label one of the machinesets to indicate the rhel-10 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-10

For bonus points, you could use a rhel-10 boot image for AWS/GCP from here. Adding a rhel-10 bootimage for Azure/vSphere is slightly more involved than editing in a reference, but should work as well. This is not strictly required since this code is platform agnostic.

3. This should trigger a reconciliation loop in the boot image controller. Examine the controller logs, it should state that the update was skipped.
4. Now, label the machineset to indicate the rhel-9 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-9

Note: On AWS, if you've used a rhel-10 AMI in step (2), set it back to any rhel-9 AMI. This is because the boot image controller uses a whitelist for updates and the rhel-10 AMI wouldn't be in the whitelist; resulting in a skipped update.

5. This should trigger a reconciliation loop and the machineset should now be set to a rhel-9 bootimage defined by rhcos.json.

Summary by CodeRabbit

• New Features
• Boot image management now supports multiple operating system streams with automatic configuration detection and validation
• Boot image updates intelligently skip Windows systems and unsupported OS stream configurations to prevent installation conflicts and ensure compatibility
• Enhanced infrastructure management for diverse operating system stream types including RHEL-9 support

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]

@djoshy: This pull request references MCO-2151 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.22.0" version, but no target version was set.

Details

In response to this:

- What I did
Added stream label detection for the boot image controller. If no label is found, it is considered an older pre "dual stream" machineset and is updated for backwards compatibility. If a label is found, it is checked against the currently supported stream in the boot image controller, and updated if it is a match.

I also took this opportunity to clean up a couple of unrelated comments.

- How to verify it
All existing bootimage e2es should pass.

1. Create a GCP/AWS/Azure/Vsphere cluster
2. Label one of the machinesets to indicate the rhel-10 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-10

For bonus points, you could use a rhel-10 boot image for AWS/GCP from here. Adding a rhel-10 bootimage for Azure/vSphere is slightly more involved than editing in a reference, but should work as well. This is not strictly required since this code is platform agnostic.

3. This should trigger a reconciliation loop in the boot image controller. Examine the controller logs, it should state that the update was skipped.
4. Now, label the machineset to indicate the rhel-9 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-9

Note: On AWS, if you've used a rhel-10 AMI in step (2), set it back to any rhel-9 AMI. This is because the boot image controller uses a whitelist for updates and the rhel-10 AMI wouldn't be in the whitelist; resulting in a skipped update.

5. This should trigger a reconciliation loop and the machineset should now be set to a rhel-9 bootimage defined by rhcos.json.

Summary by CodeRabbit

• New Features
• Boot image management now recognizes and respects OS stream labels, enabling support for distinct OS streams (including RHEL-9).
• Boot image updates will automatically skip Windows systems and machines labeled for unsupported/non-default OS streams to avoid incompatible changes.

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]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@pkg/controller/bootimage/cpms_helpers.go`:
- Around line 116-118: The log message prints arguments in the wrong slots; in
the klog.Infof call that checks controlPlaneMachineSet.GetOwnerReferences(),
swap the two arguments so the first %s receives controlPlaneMachineSet.Name and
the second %v receives the owner reference value
(controlPlaneMachineSet.GetOwnerReferences()[0].Kind+"/"+controlPlaneMachineSet.GetOwnerReferences()[0].Name);
update the klog.Infof invocation in the same block (the code referencing
controlPlaneMachineSet and GetOwnerReferences()) to reflect this corrected
ordering and keep the early return unchanged.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 29253f44-6d22-4260-9602-e5e8da21b9b4

📥 Commits

Reviewing files that changed from the base of the PR and between 14a163a and 6409e62.

📒 Files selected for processing (3)

• pkg/controller/bootimage/boot_image_controller.go
• pkg/controller/bootimage/cpms_helpers.go
• pkg/controller/bootimage/ms_helpers.go

🚧 Files skipped from review as they are similar to previous changes (2)

• pkg/controller/bootimage/boot_image_controller.go
• pkg/controller/bootimage/ms_helpers.go

[openshift-ci-robot]

@djoshy: This pull request references MCO-2151 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.22.0" version, but no target version was set.

Details

In response to this:

- What I did
Added stream label detection for the boot image controller. If no label is found, it is considered an older pre "dual stream" machineset and is updated for backwards compatibility. If a label is found, it is checked against the currently supported stream in the boot image controller, and updated if it is a match.

I also took this opportunity to clean up a couple of unrelated comments.

- How to verify it
All existing bootimage e2es should pass.

1. Create a GCP/AWS/Azure/Vsphere cluster
2. Label one of the machinesets to indicate the rhel-10 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-10

For bonus points, you could use a rhel-10 boot image for AWS/GCP from here. Adding a rhel-10 bootimage for Azure/vSphere is slightly more involved than editing in a reference, but should work as well. This is not strictly required since this code is platform agnostic.

3. This should trigger a reconciliation loop in the boot image controller. Examine the controller logs, it should state that the update was skipped.
4. Now, label the machineset to indicate the rhel-9 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-9

Note: On AWS, if you've used a rhel-10 AMI in step (2), set it back to any rhel-9 AMI. This is because the boot image controller uses a whitelist for updates and the rhel-10 AMI wouldn't be in the whitelist; resulting in a skipped update.

5. This should trigger a reconciliation loop and the machineset should now be set to a rhel-9 bootimage defined by rhcos.json.

Summary by CodeRabbit

• New Features

• Boot image management now honors OS stream labels and adds explicit support for RHEL-9 streams.

• Systems labeled for non-default OS streams or Windows are skipped to prevent incompatible boot image changes.

• Bug Fixes / Improvements

• Improved pre-checks and logging around owner references and skip decisions to make reconcile outcomes clearer.

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]

@djoshy: This pull request references MCO-2151 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.22.0" version, but no target version was set.

Details

In response to this:

- What I did
Added stream label detection for the boot image controller. If no label is found, it is considered an older pre "dual stream" machineset/controlplanemachineset and is updated for backwards compatibility. If a label is found, it is checked against the currently supported stream in the boot image controller, and updated if it is a match.

I also took this opportunity to clean up a couple of unrelated logs/comments.

- How to verify it
All existing bootimage e2es should pass.

1. Create a GCP/AWS/Azure/Vsphere cluster
2. Label one of the machinesets to indicate the rhel-10 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-10

For bonus points, you could use a rhel-10 boot image for AWS/GCP from here. Adding a rhel-10 bootimage for Azure/vSphere is slightly more involved than editing in a reference, but should work as well. This is not strictly required since this code is platform agnostic.

3. This should trigger a reconciliation loop in the boot image controller. Examine the controller logs, it should state that the update was skipped.
4. Now, label the machineset to indicate the rhel-9 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-9

Note: On AWS, if you've used a rhel-10 AMI in step (2), set it back to any rhel-9 AMI. This is because the boot image controller uses a whitelist for updates and the rhel-10 AMI wouldn't be in the whitelist; resulting in a skipped update.

5. This should trigger a reconciliation loop and the machineset should now be set to a rhel-9 bootimage defined by rhcos.json.

Summary by CodeRabbit

• New Features
• Boot image management now recognizes and respects OS stream labels, enabling support for distinct OS streams (including RHEL-9).
• Boot image updates will automatically skip Windows systems and machines labeled for unsupported/non-default OS streams to avoid incompatible changes.

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]

@djoshy: This pull request references MCO-2151 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.22.0" version, but no target version was set.

Details

In response to this:

- What I did
Added stream label detection for the boot image controller. If no label is found, it is considered an older pre "dual stream" machineset/controlplanemachineset and is updated for backwards compatibility. If a label is found, it is checked against the currently supported stream in the boot image controller, and then reconciled if it is a match.

I also took this opportunity to clean up a couple of unrelated logs/comments.

- How to verify it
All existing bootimage e2es should pass.

1. Create a GCP/AWS/Azure/Vsphere cluster
2. Label one of the machinesets to indicate the rhel-10 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-10

For bonus points, you could use a rhel-10 boot image for AWS/GCP from here. Adding a rhel-10 bootimage for Azure/vSphere is slightly more involved than editing in a reference, but should work as well. This is not strictly required since this code is platform agnostic.

3. This should trigger a reconciliation loop in the boot image controller. Examine the controller logs, it should state that the update was skipped.
4. Now, label the machineset to indicate the rhel-9 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-9

Note: On AWS, if you've used a rhel-10 AMI in step (2), set it back to any rhel-9 AMI. This is because the boot image controller uses a whitelist for updates and the rhel-10 AMI wouldn't be in the whitelist; resulting in a skipped update.

5. This should trigger a reconciliation loop and the machineset should now be set to a rhel-9 bootimage defined by rhcos.json.

Summary by CodeRabbit

• New Features
• Boot image management now recognizes and respects OS stream labels, enabling support for distinct OS streams (including RHEL-9).
• Boot image updates will automatically skip Windows systems and machines labeled for unsupported/non-default OS streams to avoid incompatible changes.

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]

/retest

[openshift-ci-robot]

@djoshy: This pull request references MCO-2151 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.22.0" version, but no target version was set.

Details

In response to this:

- What I did
Added stream label detection for the boot image controller. If no label is found, it is considered an older pre "dual stream" machineset/controlplanemachineset and is updated for backwards compatibility. If a label is found, it is checked against the currently supported stream in the boot image controller, and then reconciled if it is a match.

I also took this opportunity to clean up a couple of unrelated logs/comments.

- How to verify it
All existing bootimage e2es should pass.

1. Create a GCP/AWS/Azure/Vsphere cluster
2. Label one of the machinesets to indicate the rhel-10 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-10

For bonus points, you could use a rhel-10 boot image for AWS/GCP from here. Adding a rhel-10 bootimage for Azure/vSphere is slightly more involved than editing in a reference, but should work as well. This is not strictly required since this code is platform agnostic.

3. This should trigger a reconciliation loop in the boot image controller. Examine the controller logs, it should state that the update was skipped.

ms_helpers.go:126] machineset ci-ln-97wxgxb-72292-bg8vs-worker-b has unsupported stream: rhel-10, skipping boot image update

4. Now, label the machineset to indicate the rhel-9 stream:

oc label machinesets <machineset> -n openshift-machine-api machineconfiguration.openshift.io/osstream=rhel-9

Note: On AWS, if you've used a rhel-10 AMI in step (2), set it back to any rhel-9 AMI. This is because the boot image controller uses a whitelist for updates and the rhel-10 AMI wouldn't be in the whitelist; resulting in a skipped update.

5. This should trigger a reconciliation loop and the machineset should now be set to a rhel-9 bootimage defined by rhcos.json.

Summary by CodeRabbit

• New Features
• Boot image management now recognizes and respects OS stream labels, enabling support for distinct OS streams (including RHEL-9).
• Boot image updates will automatically skip Windows systems and machines labeled for unsupported/non-default OS streams to avoid incompatible changes.

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.

[isabella-janssen]

/lgtm

Change seems fair to me, thanks @djoshy 🎉

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: djoshy, isabella-janssen

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 [djoshy,isabella-janssen]

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

[pablintino]

/retest-required

[djoshy]

/retest

[djoshy]

/test all

[djoshy]

/retest

[djoshy]

/retest

[djoshy]

/retest

[openshift-ci]

@djoshy: The following tests 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-gcp-op-ocl-part1	d0665d7	link	false	/test e2e-gcp-op-ocl-part1
ci/prow/e2e-aws-ovn	d0665d7	link	true	/test e2e-aws-ovn
ci/prow/e2e-hypershift	d0665d7	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.