[DNM] MCO-2249: Custom Pool Booting on Day 0 prototype#10528
[DNM] MCO-2249: Custom Pool Booting on Day 0 prototype#10528djoshy wants to merge 4 commits intoopenshift:mainfrom
Conversation
|
Skipping CI for Draft Pull Request. |
WalkthroughThe changes introduce Day 0 custom machine pool support by adding validation for arbitrary DNS-label-compliant pool names (with platform and count restrictions), generating per-pool ignition configurations and MachineConfigPool manifests, integrating custom pool asset generation into the Worker asset, and auto-balancing worker replica counts when not explicitly specified. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 9 | ❌ 3❌ Failed checks (2 warnings, 1 inconclusive)
✅ Passed checks (9 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
pkg/asset/machines/worker.go (1)
342-378: 💤 Low valueWorker replica detection via raw YAML parsing is functional but fragile.
The approach of re-parsing the raw install-config YAML to detect whether
replicaswas explicitly set works, but couples this logic to the YAML structure. If the install-config parsing changes or the field is renamed, this could silently break.Consider documenting this dependency or adding a test that verifies the detection works correctly when replicas are explicitly set vs defaulted.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@pkg/asset/machines/worker.go` around lines 342 - 378, Add a unit test and brief comment to make the fragile raw-YAML detection explicit: create tests for the logic around workerReplicasExplicitlySet (the rawIC struct + yaml.Unmarshal of installConfig.File.Data) that cover cases where the compute pool for types.MachinePoolComputeRoleName explicitly sets replicas and where it relies on defaults; in the code near the rawIC parsing add a short comment calling out the dependency on the install-config YAML shape so future refactors notice the coupling.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@pkg/asset/machines/worker.go`:
- Around line 342-378: Add a unit test and brief comment to make the fragile
raw-YAML detection explicit: create tests for the logic around
workerReplicasExplicitlySet (the rawIC struct + yaml.Unmarshal of
installConfig.File.Data) that cover cases where the compute pool for
types.MachinePoolComputeRoleName explicitly sets replicas and where it relies on
defaults; in the code near the rawIC parsing add a short comment calling out the
dependency on the install-config YAML shape so future refactors notice the
coupling.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 855c7881-ae9e-467e-aa6a-1e4c80873a82
📒 Files selected for processing (10)
docs/design/custom-machine-pools-day0.mdpkg/asset/ignition/machine/custompool.gopkg/asset/machines/gcp/machines.gopkg/asset/machines/machineconfigpool/manifest.gopkg/asset/machines/worker.gopkg/asset/machines/worker_test.gopkg/asset/manifests/mco.gopkg/types/defaults/machinepools.gopkg/types/machinepools.gopkg/types/validation/installconfig.go
|
@djoshy: This pull request references MCO-2249 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 "5.0.0" version, but no target version was set. DetailsIn response to this:
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. |
Implementation details can be found in
docs/design/custom-machine-pools-day0.mdattached to this PR. Scrapes from a sample run below:InstallConfig used:
Note that I've specified a different bootimage for each of the custom pools. Post installation, we have:
Examining the aleph version on each node indicates they used the bootimages we have defined:
Both nodes pivoted to the rhel-9 stream after firstboot, as that is the default currently.
Summary by CodeRabbit