MCO-2293: adds RHEL10 featuregate#2860
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
openshift-ci-robot
added
the
jira/valid-reference
|
@cheesesashimi: This pull request references MCO-2293 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. |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (11)
✅ Files skipped from review due to trivial changes (3)
🚧 Files skipped from review as they are similar to previous changes (7)
📝 WalkthroughWalkthroughThis PR adds a new OpenShift FeatureGate RHCOS10DefaultInstall (declared and registered in Go with version/profile-aware enablement), updates the features.md matrix, and modifies/adds FeatureGate payload manifests: a new 5-10 SelfManagedHA Default manifest and edits to several 4.x and 4-10 SelfManagedHA and Hypershift manifests to mark the gate enabled or disabled per release/profile. Suggested reviewers
🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 golangci-lint (2.12.2)Error: build linters: unable to load custom analyzer "kubeapilinter": tools/_output/bin/kube-api-linter.so, plugin: not implemented Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Skipping CI for Draft Pull Request. |
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
|
Hello @cheesesashimi! Some important instructions when contributing to openshift/api: |
openshift-ci
Bot
added
the
size/M
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@payload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yaml`:
- Around line 251-253: The manifest currently hard-disables the "RHEL10" feature
with a single status entry (version: "") which conflicts with the code-enabled
RHEL10 for >=5; update the 4-10 feature-gate manifest so RHEL10 has
version-specific status entries (e.g., an explicit disabled entry for versions
<5 and either no entry or an enabled entry for versions >=5) or split into
per-major manifests so 4.x keeps it disabled and 5+ resolves to enabled,
ensuring the unique feature name "RHEL10" is adjusted accordingly in the
manifest entries to match the version-gated behavior in features.go.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: e7d6492b-243b-4292-a92d-66ba7822f8d4
📒 Files selected for processing (10)
features.mdfeatures/features.gopayload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yamlpayload-manifests/featuregates/featureGate-4-10-Hypershift-DevPreviewNoUpgrade.yamlpayload-manifests/featuregates/featureGate-4-10-Hypershift-OKD.yamlpayload-manifests/featuregates/featureGate-4-10-Hypershift-TechPreviewNoUpgrade.yamlpayload-manifests/featuregates/featureGate-4-10-SelfManagedHA-Default.yamlpayload-manifests/featuregates/featureGate-4-10-SelfManagedHA-DevPreviewNoUpgrade.yamlpayload-manifests/featuregates/featureGate-4-10-SelfManagedHA-OKD.yamlpayload-manifests/featuregates/featureGate-4-10-SelfManagedHA-TechPreviewNoUpgrade.yaml
| { | ||
| "name": "RHEL10" | ||
| }, |
There was a problem hiding this comment.
Static disable conflicts with version-gated enablement.
RHEL10 is enabled in features/features.go at Line 891 for version >=5, but this 4-10 manifest hard-disables it in the only status entry (version: ""). That mismatch can keep 5+ behavior/docs incorrect. Please represent RHEL10 with version-specific status entries (or equivalent per-major manifest split) so 4.x and 5+ resolve differently.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@payload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yaml`
around lines 251 - 253, The manifest currently hard-disables the "RHEL10"
feature with a single status entry (version: "") which conflicts with the
code-enabled RHEL10 for >=5; update the 4-10 feature-gate manifest so RHEL10 has
version-specific status entries (e.g., an explicit disabled entry for versions
<5 and either no entry or an enabled entry for versions >=5) or split into
per-major manifests so 4.x keeps it disabled and 5+ resolves to enabled,
ensuring the unique feature name "RHEL10" is adjusted accordingly in the
manifest entries to match the version-gated behavior in features.go.
|
[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 |
| enable(inTechPreviewNoUpgrade(), inDevPreviewNoUpgrade()). | ||
| mustRegister() | ||
|
|
||
| FeatureGateRHEL10 = newFeatureGate("RHEL10"). |
There was a problem hiding this comment.
IIUC the intent of this feature gate is to default installs to RHCOS10 (which will never happen in 4.x), so I would suggest:
| FeatureGateRHEL10 = newFeatureGate("RHEL10"). | |
| FeatureGateRHCOS10DefaultInstall = newFeatureGate("RHCOS10DefaultInstall"). |
or something of that variety.
Note that including the substring Install in the feature gate switches the promotion criteria so that the tests will look at install success, rather than e2e test cases. Prioritizing these tests makes sense as the os stream feature gate should cover the e2e side of things.
There was a problem hiding this comment.
I'll adjust it to your suggestion, thanks!
cheesesashimi
force-pushed
the
zzlotnik/rhel10-feature-gate
branch
from
016b634 to
11f4856
Compare
There was a problem hiding this comment.
♻️ Duplicate comments (5)
payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-Default.yaml (1)
122-124:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVersion-gated enablement conflicts with static manifest disable.
The feature gate is enabled for version ≥5 in
features/features.goat line 891, but this SelfManagedHA Default manifest covering versions 4-10 disables it unconditionally. Clusters running OCP 5.0+ will experience a conflict between the code-level enablement and the manifest state. Implement version-specific status entries or split manifests by major version.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-Default.yaml` around lines 122 - 124, The manifest "featureGate-4-10-SelfManagedHA-Default.yaml" currently unconditionally lists the "DefaultRHEL10" disable entry which conflicts with the version-gated enablement in features/features.go (enabled for OCP ≥5); update the manifest to be version-aware by either splitting this manifest into separate major-version manifests (e.g., 4.x vs 5.x) or adding explicit version-scoped status entries (minVersion/maxVersion) so "DefaultRHEL10" is not disabled for clusters running OCP 5.0+ and aligns with the feature gate logic in features/features.go.payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-OKD.yaml (1)
124-126:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVersion-gated enablement conflicts with static manifest disable.
DefaultRHEL10is enabled for version ≥5 infeatures/features.go(line 891), yet this OKD manifest for versions 4-10 disables it withversion: "". In OCP 5.0+, the feature gate will be incorrectly reported as disabled. Resolve by using version-specific status entries or creating separate manifests for v4 and v5+.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-OKD.yaml` around lines 124 - 126, The manifest currently disables the feature gate "DefaultRHEL10" for the 4-10 OKD payload which conflicts with the code-level gating that enables DefaultRHEL10 for versions >= 5 in features/features.go; update the manifest so version-specific status is used (add a status entry that enables DefaultRHEL10 for v5+ while keeping it disabled for v4) or split this manifest into two manifests (one for v4 with version: "" disabling DefaultRHEL10 and one for v5+ that explicitly sets the feature status to enabled) to ensure the runtime feature state matches the version-gated logic in the feature gate implementation.payload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yaml (1)
125-127:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVersion-gated enablement conflicts with static manifest disable.
DefaultRHEL10is enabled infeatures/features.goat line 891 for version ≥5 viaenable(inVersion(5, greaterThanOrEqual)), but this 4-10 manifest unconditionally disables it (version: ""). For OCP 5.0+ clusters, the runtime behavior will conflict with the documented/intended state. Consider version-specific status entries or splitting manifests by major version so v5+ reflects the enabled state.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@payload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yaml` around lines 125 - 127, The manifest entry for feature "DefaultRHEL10" unconditionally disables it (empty version/status) which conflicts with the code-level enablement in features.go where DefaultRHEL10 is enabled via enable(inVersion(5, greaterThanOrEqual)); update the feature gate manifest so runtime state matches code by either adding a version-scoped status entry (e.g., set status disabled for versions <5 and enabled for ≥5) or split the manifest into per-major-version files so the 5.x+ manifest reflects the enabled state for DefaultRHEL10; locate the symbol "DefaultRHEL10" in the manifest and reconcile it with the enable(inVersion(5, greaterThanOrEqual)) rule in features/features.go.payload-manifests/featuregates/featureGate-4-10-Hypershift-DevPreviewNoUpgrade.yaml (1)
25-27:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVersion-gated enablement conflicts with static manifest disable.
DefaultRHEL10is enabled infeatures/features.goat line 891 for version ≥5, but this DevPreviewNoUpgrade manifest spanning versions 4-10 hard-disables it. For v5+ clusters, this creates a mismatch between code enablement and manifest configuration. Use version-specific status entries or separate manifests per major version.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@payload-manifests/featuregates/featureGate-4-10-Hypershift-DevPreviewNoUpgrade.yaml` around lines 25 - 27, The manifest hard-disables the feature named "DefaultRHEL10" while the code in features/features.go enables that same feature for version ≥5, creating a conflict; update this DevPreviewNoUpgrade manifest so it does not blanket-disable DefaultRHEL10 across 4-10—either add version-specific status entries in this manifest that keep it disabled only for pre-v5 ranges or split this file into separate manifests per major version (e.g., 4.x vs 5.x) so that DefaultRHEL10 remains enabled for v5+ clusters as defined in features/features.go.payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-TechPreviewNoUpgrade.yaml (1)
37-39:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftVersion-gated enablement conflicts with static manifest disable.
The code in
features/features.goat line 891 enablesDefaultRHEL10for version ≥5, but this TechPreviewNoUpgrade manifest for versions 4-10 unconditionally disables it. OCP 5.0+ clusters will see a mismatch between intended enablement and the manifest configuration. Use version-specific status entries or split the manifest by major version.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-TechPreviewNoUpgrade.yaml` around lines 37 - 39, The manifest unconditionally disables the feature named "DefaultRHEL10" for 4-10 while the feature enablement logic in features.go (the DefaultRHEL10 gating around version ≥5) will turn it on for OCP 5+, causing a conflict; fix by making the manifest version-aware — either add version-scoped status entries so "DefaultRHEL10" is disabled only for <5 and not for ≥5, or split this TechPreviewNoUpgrade manifest into separate major-version manifests (one for 4.x that keeps the disable, and one for 5.x+ that omits or sets the feature to enabled), ensuring the manifest status for "DefaultRHEL10" matches the gating logic in features.go.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In `@payload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yaml`:
- Around line 125-127: The manifest entry for feature "DefaultRHEL10"
unconditionally disables it (empty version/status) which conflicts with the
code-level enablement in features.go where DefaultRHEL10 is enabled via
enable(inVersion(5, greaterThanOrEqual)); update the feature gate manifest so
runtime state matches code by either adding a version-scoped status entry (e.g.,
set status disabled for versions <5 and enabled for ≥5) or split the manifest
into per-major-version files so the 5.x+ manifest reflects the enabled state for
DefaultRHEL10; locate the symbol "DefaultRHEL10" in the manifest and reconcile
it with the enable(inVersion(5, greaterThanOrEqual)) rule in
features/features.go.
In
`@payload-manifests/featuregates/featureGate-4-10-Hypershift-DevPreviewNoUpgrade.yaml`:
- Around line 25-27: The manifest hard-disables the feature named
"DefaultRHEL10" while the code in features/features.go enables that same feature
for version ≥5, creating a conflict; update this DevPreviewNoUpgrade manifest so
it does not blanket-disable DefaultRHEL10 across 4-10—either add
version-specific status entries in this manifest that keep it disabled only for
pre-v5 ranges or split this file into separate manifests per major version
(e.g., 4.x vs 5.x) so that DefaultRHEL10 remains enabled for v5+ clusters as
defined in features/features.go.
In `@payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-Default.yaml`:
- Around line 122-124: The manifest
"featureGate-4-10-SelfManagedHA-Default.yaml" currently unconditionally lists
the "DefaultRHEL10" disable entry which conflicts with the version-gated
enablement in features/features.go (enabled for OCP ≥5); update the manifest to
be version-aware by either splitting this manifest into separate major-version
manifests (e.g., 4.x vs 5.x) or adding explicit version-scoped status entries
(minVersion/maxVersion) so "DefaultRHEL10" is not disabled for clusters running
OCP 5.0+ and aligns with the feature gate logic in features/features.go.
In `@payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-OKD.yaml`:
- Around line 124-126: The manifest currently disables the feature gate
"DefaultRHEL10" for the 4-10 OKD payload which conflicts with the code-level
gating that enables DefaultRHEL10 for versions >= 5 in features/features.go;
update the manifest so version-specific status is used (add a status entry that
enables DefaultRHEL10 for v5+ while keeping it disabled for v4) or split this
manifest into two manifests (one for v4 with version: "" disabling DefaultRHEL10
and one for v5+ that explicitly sets the feature status to enabled) to ensure
the runtime feature state matches the version-gated logic in the feature gate
implementation.
In
`@payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-TechPreviewNoUpgrade.yaml`:
- Around line 37-39: The manifest unconditionally disables the feature named
"DefaultRHEL10" for 4-10 while the feature enablement logic in features.go (the
DefaultRHEL10 gating around version ≥5) will turn it on for OCP 5+, causing a
conflict; fix by making the manifest version-aware — either add version-scoped
status entries so "DefaultRHEL10" is disabled only for <5 and not for ≥5, or
split this TechPreviewNoUpgrade manifest into separate major-version manifests
(one for 4.x that keeps the disable, and one for 5.x+ that omits or sets the
feature to enabled), ensuring the manifest status for "DefaultRHEL10" matches
the gating logic in features.go.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 5fe9b4a8-34ee-44de-8367-db5284d24773
📒 Files selected for processing (10)
features.mdfeatures/features.gopayload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yamlpayload-manifests/featuregates/featureGate-4-10-Hypershift-DevPreviewNoUpgrade.yamlpayload-manifests/featuregates/featureGate-4-10-Hypershift-OKD.yamlpayload-manifests/featuregates/featureGate-4-10-Hypershift-TechPreviewNoUpgrade.yamlpayload-manifests/featuregates/featureGate-4-10-SelfManagedHA-Default.yamlpayload-manifests/featuregates/featureGate-4-10-SelfManagedHA-DevPreviewNoUpgrade.yamlpayload-manifests/featuregates/featureGate-4-10-SelfManagedHA-OKD.yamlpayload-manifests/featuregates/featureGate-4-10-SelfManagedHA-TechPreviewNoUpgrade.yaml
✅ Files skipped from review due to trivial changes (1)
- features.md
🚧 Files skipped from review as they are similar to previous changes (3)
- payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-DevPreviewNoUpgrade.yaml
- payload-manifests/featuregates/featureGate-4-10-Hypershift-TechPreviewNoUpgrade.yaml
- payload-manifests/featuregates/featureGate-4-10-Hypershift-OKD.yaml
cheesesashimi
force-pushed
the
zzlotnik/rhel10-feature-gate
branch
from
11f4856 to
52a66bb
Compare
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@payload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yaml`:
- Around line 251-253: The manifest currently disables the
"RHCOS10DefaultInstall" feature for all versions because the featureGates entry
uses version: "" while the code (features/features.go via enable(inVersion(5,
greaterThanOrEqual))) expects it enabled for v>=5; update the manifest to match
the code by removing "RHCOS10DefaultInstall" from the global disabled list or
split the featureGates into version-specific entries so that it's explicitly
disabled for v<5 and absent/enabled for v>=5 (alternatively create separate
per-major-version manifests), ensuring the entry that references
"RHCOS10DefaultInstall" is scoped to the correct version range to avoid the
mismatch.
In
`@payload-manifests/featuregates/featureGate-4-10-Hypershift-DevPreviewNoUpgrade.yaml`:
- Around line 61-63: The manifest's featureGates block is applying a disabled
list to all versions because the single entry uses version: "" which overrides
code's intent (features/features.go where RHCOS10DefaultInstall is enabled for
version >=5); update the manifest to make featureGates version-specific (e.g.,
add an entry with version ">=5" that enables RHCOS10DefaultInstall or split into
per-major-version manifests) so that RHCOS10DefaultInstall is not globally
disabled and matches the code's >=5 enablement.
In `@payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-Default.yaml`:
- Around line 245-247: Manifest currently lists "RHCOS10DefaultInstall" in the
disabled/global entry that applies to all versions, which conflicts with the
enablement logic in features/features.go that enables RHCOS10DefaultInstall for
version >=5; update the manifest so the gate is disabled for v4 but enabled for
v5+ by adding version-scoped featureGates (or split into per-major-version
manifests) instead of a single version:"" entry—ensure the manifest's
featureGates entries align with the RHCOS10DefaultInstall enablement in
features/features.go so v5+ operators see it enabled while v4 remains disabled.
In
`@payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-TechPreviewNoUpgrade.yaml`:
- Around line 67-69: The manifest currently lists "RHCOS10DefaultInstall" in the
global disabled list, which conflicts with the logic in features/features.go
that enables RHCOS10DefaultInstall for operator versions >=5; update the
manifest so the gate is disabled for v4.x but enabled for v5+ — either split the
global featureGates into version-specific entries (add a specific entry for
major version 4 that includes "RHCOS10DefaultInstall" in disabled, and a
separate entry for versions 5+ that does not list it) or create
per-major-version manifests so the runtime behavior of RHCOS10DefaultInstall
matches the code path in features/features.go.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: ec3fe993-7623-46dc-9931-1142a978daf1
📒 Files selected for processing (10)
features.mdfeatures/features.gopayload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yamlpayload-manifests/featuregates/featureGate-4-10-Hypershift-DevPreviewNoUpgrade.yamlpayload-manifests/featuregates/featureGate-4-10-Hypershift-OKD.yamlpayload-manifests/featuregates/featureGate-4-10-Hypershift-TechPreviewNoUpgrade.yamlpayload-manifests/featuregates/featureGate-4-10-SelfManagedHA-Default.yamlpayload-manifests/featuregates/featureGate-4-10-SelfManagedHA-DevPreviewNoUpgrade.yamlpayload-manifests/featuregates/featureGate-4-10-SelfManagedHA-OKD.yamlpayload-manifests/featuregates/featureGate-4-10-SelfManagedHA-TechPreviewNoUpgrade.yaml
✅ Files skipped from review due to trivial changes (3)
- features.md
- payload-manifests/featuregates/featureGate-4-10-Hypershift-TechPreviewNoUpgrade.yaml
- payload-manifests/featuregates/featureGate-4-10-Hypershift-OKD.yaml
🚧 Files skipped from review as they are similar to previous changes (2)
- payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-OKD.yaml
- payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-DevPreviewNoUpgrade.yaml
| { | ||
| "name": "RHCOS10DefaultInstall" | ||
| }, |
There was a problem hiding this comment.
Version mismatch: gate enabled for v5+ in code but disabled in cross-version manifest.
This manifest covers versions 4,5,6,7,8,9,10 (line 8) but has a single featureGates entry with version: "" (line 365), meaning the disabled list applies to all versions. However, features/features.go line 891 enables this gate for version >=5 via enable(inVersion(5, greaterThanOrEqual)). Operators reading this manifest for v5+ will see RHCOS10DefaultInstall as disabled, conflicting with the code definition.
Consider splitting into version-specific entries (disabled for v<5, enabled/absent for v>=5) or separate per-major-version manifests so v4.x shows disabled and v5+ resolves to enabled.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@payload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yaml`
around lines 251 - 253, The manifest currently disables the
"RHCOS10DefaultInstall" feature for all versions because the featureGates entry
uses version: "" while the code (features/features.go via enable(inVersion(5,
greaterThanOrEqual))) expects it enabled for v>=5; update the manifest to match
the code by removing "RHCOS10DefaultInstall" from the global disabled list or
split the featureGates into version-specific entries so that it's explicitly
disabled for v<5 and absent/enabled for v>=5 (alternatively create separate
per-major-version manifests), ensuring the entry that references
"RHCOS10DefaultInstall" is scoped to the correct version range to avoid the
mismatch.
| { | ||
| "name": "RHCOS10DefaultInstall" | ||
| }, |
There was a problem hiding this comment.
Version mismatch: gate enabled for v5+ in code but disabled in cross-version manifest.
This manifest covers versions 4,5,6,7,8,9,10 (line 8) but has a single featureGates entry with version: "" (line 367), applying the disabled list to all versions. features/features.go line 891 enables RHCOS10DefaultInstall for version >=5, but this manifest will show it as disabled for v5+ operators, conflicting with the code definition.
Consider version-specific entries or per-major-version manifests so v4.x and v5+ resolve correctly.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@payload-manifests/featuregates/featureGate-4-10-Hypershift-DevPreviewNoUpgrade.yaml`
around lines 61 - 63, The manifest's featureGates block is applying a disabled
list to all versions because the single entry uses version: "" which overrides
code's intent (features/features.go where RHCOS10DefaultInstall is enabled for
version >=5); update the manifest to make featureGates version-specific (e.g.,
add an entry with version ">=5" that enables RHCOS10DefaultInstall or split into
per-major-version manifests) so that RHCOS10DefaultInstall is not globally
disabled and matches the code's >=5 enablement.
| contactPerson("zzlotnik"). | ||
| productScope(ocpSpecific). | ||
| enhancementPR("https://github.com/openshift/enhancements/pull/1874"). | ||
| enable(inVersion(5, greaterThanOrEqual)). |
There was a problem hiding this comment.
No featuresets here yet, is that deliberate?
There was a problem hiding this comment.
I just pushed an update which adds featuresets as follows:
- In >= 5.0, RHCOS10 is installed by default on new clusters.
- In < 5.0, RHCOS10 is installed by default only in new TechPreview clusters. Newly installed non-TechPreview clusters will continue to default to RHCOS9.
- Install-time Hypershift support is still TBD right now, so this will only apply to self-managed clusters.
These are the featuresets that I think are correct, but I'm currently confirming that.
openshift-ci
Bot
added
needs-rebase
cheesesashimi
force-pushed
the
zzlotnik/rhel10-feature-gate
branch
from
e3ea905 to
506967c
Compare
openshift-ci
Bot
removed
the
needs-rebase
|
@cheesesashimi: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
4 participants
The intent behind this FeatureGate is to enable RHEL10 by default in OCP 5.0 while allowing OCP 4.23 to opt into it, if desired. As of right now, there are still a few TODOs and tweaks that need to be done for this to have the desired effect.