AUTOSCALE-827: add KarpenterOperator feature gate

[maxcao13]

Adds the KarpenterOperator feature gate to OpenShift.

It will start in DevPreviewNoUpgrade, and follow the promotion process detailed in the enhancement PR. It will be enable-able in both selfmanaged(standalone), and HCP.

Refer to openshift/enhancements#2007 for details.

[openshift-merge-bot]

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-robot]

@maxcao13: This pull request references AUTOSCALE-827 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 task to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Adds the KarpenterOperator feature gate to OpenShift.

It will start in DevPreviewNoUpgrade, and follow the promotion process detailed in the enhancement PR. It will be enable-able in both selfmanaged(standalone), and HCP.

Refer to openshift/enhancements#2007 for 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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[openshift-ci]

Hello @maxcao13! 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]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 1c20f9d6-1ff2-4a81-9b6e-e1ee50afeb80

📥 Commits

Reviewing files that changed from the base of the PR and between 1d86025 and 0b97f9b.

📒 Files selected for processing (10)

• features.md
• features/features.go
• payload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yaml
• payload-manifests/featuregates/featureGate-4-10-Hypershift-DevPreviewNoUpgrade.yaml
• payload-manifests/featuregates/featureGate-4-10-Hypershift-OKD.yaml
• payload-manifests/featuregates/featureGate-4-10-Hypershift-TechPreviewNoUpgrade.yaml
• payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-Default.yaml
• payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-DevPreviewNoUpgrade.yaml
• payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-OKD.yaml
• payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-TechPreviewNoUpgrade.yaml

✅ Files skipped from review due to trivial changes (1)

• payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-OKD.yaml

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

• features/features.go

---

📝 Walkthrough

Walkthrough

A new exported feature gate, FeatureGateKarpenterOperator, is added to features/features.go with reporting metadata and an enablement condition for SelfManaged clusters in inDevPreviewNoUpgrade(). features.md adds a KarpenterOperator row, and the affected feature-gate payload manifests are updated to include KarpenterOperator in the enabled or disabled lists shown in the diff.

Suggested reviewers

• JoelSpeed

🚥 Pre-merge checks | ✅ 15

✅ Passed checks (15 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly matches the change: adding the KarpenterOperator feature gate.
Description check	✅ Passed	The description is directly related to the PR and accurately describes the new feature gate rollout.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names	✅ Passed	The PR only changes feature-gate code, docs, and manifests; no Ginkgo tests or titles were added or modified.
Test Structure And Quality	✅ Passed	No Ginkgo test code was modified; the PR only changes feature-gate registry/docs/YAML, so the test-quality checklist isn’t applicable.
Microshift Test Compatibility	✅ Passed	No new Ginkgo tests were added; the PR only changes feature-gate registration/docs/manifests, so MicroShift compatibility isn’t impacted.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	No new Ginkgo e2e specs were added; the touched test file is a plain unit test and contains no multi-node/SNO assumptions.
Topology-Aware Scheduling Compatibility	✅ Passed	Changes only add feature-gate metadata/manifests; no pod affinity, node selectors, replica logic, or topology-dependent scheduling code.
Ote Binary Stdout Contract	✅ Passed	PASS: the PR only adds feature-gate declarations/manifests; the new package-level builder chain and helpers contain no stdout writes or stdout logging.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	Only feature-gate source/docs/manifests changed; no new Ginkgo e2e specs or IPv4/external-connectivity assumptions were added.
No-Weak-Crypto	✅ Passed	PR only adds a feature-gate declaration and YAML manifest updates; no MD5/SHA1/DES/RC4/3DES/Blowfish/ECB or secret-comparison code was added.
Container-Privileges	✅ Passed	Changed files only add KarpenterOperator feature-gate entries; no privileged, hostPID/hostNetwork/hostIPC, allowPrivilegeEscalation, SYS_ADMIN, or root settings found.
No-Sensitive-Data-In-Logs	✅ Passed	No logging code was added; the changed files only register KarpenterOperator and update manifests/tables, with no passwords, tokens, PII, or hostnames exposed.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

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
The command is terminated due to an error: build linters: unable to load custom analyzer "kubeapilinter": tools/_output/bin/kube-api-linter.so, plugin: not implemented

---

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

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign everettraven for approval. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[enxebre]

It will be enable-able in both selfmanaged(standalone), and HCP.

what are you expecting to be the effect of enabling this in HCP? HCP management side decisions for karpenter can not be tied to the management cluster. E.g. many management clusters are not even OpenShift

[maxcao13]

what are you expecting to be the effect of enabling this in HCP? HCP management side decisions for karpenter can not be tied to the management cluster. E.g. many management clusters are not even OpenShift

The feature gate would only be used in HCP as a toggle for migration. I would think that as we progressed this refactor, eventually a hypershift vx.y.z would have the feature gate defaulted to True, and the migration would be transparent to the user.

If that doesn't make sense from what a feature gate should be, then I'm happy to only include this for standalone. For HCP, then we would just use some arbitrary eventually-defaulted flag and not use feature gates at all.

[JoelSpeed]

IIUC, for HyperShift, the gate needs to be passed to HO and then to KO, so the gate status here (which would be the status in the guest cluster OR management cluster) wouldn't have any effect right?

We need a separate change in the HCP repo to handle a gate that feeds HO behaviour right?

[maxcao13]

IIUC, for HyperShift, the gate needs to be passed to HO and then to KO, so the gate status here (which would be the status in the guest cluster OR management cluster) wouldn't have any effect right?

The way I thought it would work, is that the HO in the management cluster sees the KarpenterOperator feature gate enabled in the cluster through the FeatureGate object, and selectively either deploys karpenter-operator from the [payload]/[registry.io red hat KO image], or the legacy karpenter-operator which is embedded in hypershift repo code. So KO itself doesn't consume the gate at all on HCP or standalone.

Since Alberto mentions that many management clusters are not even OpenShift, then I realize this cannot work with openshift API feature gates for an HCP management layer feature gate then. I need to update this PR to remove the scope of HCP, and update the enhancement.

We need a separate change in the HCP repo to handle a gate that feeds HO behaviour right?

Basically yes I think:

I assume the HCP feature gate needs to be "duplicated" and go here instead: https://github.com/openshift/hypershift/blob/main/api/hypershift/v1beta1/featuregates/featureGate-Hypershift-TechPreviewNoUpgrade.yaml. IMO a feature gate makes sense for HCP just because eventually we would want to flip the refactor to default-on for GA at some version of HO, and stop maintaining the legacy code.

So then this PR is purely about standalone. Does anyone have any problems with this?

[JoelSpeed]

Does anyone have any problems with this?

Works for me now we've cleared that up

[openshift-ci]

@maxcao13: all tests passed!

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.