DevPreview: NetworkConnect feature gate

[tssurya]

This PR adds NetworkConnect DevPreview feature gate

[openshift-ci-robot]

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]

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

Walkthrough

A new NetworkConnect feature gate is introduced across the codebase. The feature is defined in Go source code with configuration metadata, documented in features.md, and registered in deployment configuration manifests for both Hypershift and SelfManagedHA profiles across four different stages (Default, DevPreviewNoUpgrade, OKD, and TechPreviewNoUpgrade).

Changes

Cohort / File(s)	Summary
Feature Gate Source Definition features.md, features/features.go, features/util.go	Added NetworkConnect feature gate documentation row and public Go definition with Jira component (Networking/ovn-kubernetes), contact person (tssurya), OCP-specific scope, and DevPreviewNoUpgrade enablement. Extended enhancement PR URL validation in util.go to support ovn-kubernetes repository format. Minor indentation adjustment to existing ImageVolume feature gate.
Hypershift Manifests payload-manifests/featuregates/featureGate-Hypershift-*.yaml	Added NetworkConnect to enabled list in DevPreviewNoUpgrade variant; added to disabled lists in Default, OKD, and TechPreviewNoUpgrade variants.
SelfManagedHA Manifests payload-manifests/featuregates/featureGate-SelfManagedHA-*.yaml	Added NetworkConnect to enabled list in DevPreviewNoUpgrade variant; added to disabled lists in Default, OKD, and TechPreviewNoUpgrade variants.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify NetworkConnect entries are correctly placed in alphabetical order across all eight YAML manifest files
• Confirm enhancement PR URL pattern validation in features/util.go correctly matches the new ovn-kubernetes repository format
• Ensure consistency of feature gate state (enabled/disabled) across Hypershift and SelfManagedHA profile variants

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

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

---

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between bfa868a and 5964209.

📒 Files selected for processing (11)

• features.md (1 hunks)
• features/features.go (2 hunks)
• features/util.go (2 hunks)
• payload-manifests/featuregates/featureGate-Hypershift-Default.yaml (1 hunks)
• payload-manifests/featuregates/featureGate-Hypershift-DevPreviewNoUpgrade.yaml (1 hunks)
• payload-manifests/featuregates/featureGate-Hypershift-OKD.yaml (1 hunks)
• payload-manifests/featuregates/featureGate-Hypershift-TechPreviewNoUpgrade.yaml (1 hunks)
• payload-manifests/featuregates/featureGate-SelfManagedHA-Default.yaml (1 hunks)
• payload-manifests/featuregates/featureGate-SelfManagedHA-DevPreviewNoUpgrade.yaml (1 hunks)
• payload-manifests/featuregates/featureGate-SelfManagedHA-OKD.yaml (1 hunks)
• payload-manifests/featuregates/featureGate-SelfManagedHA-TechPreviewNoUpgrade.yaml (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**

⚙️ CodeRabbit configuration file

-Focus on major issues impacting performance, readability, maintainability and security. Avoid nitpicks and avoid verbosity.

Files:

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

🧬 Code graph analysis (1)

features/features.go (1)

config/v1/types_feature.go (1)

• DevPreviewNoUpgrade (49-49)

🔇 Additional comments (11)

features/util.go (1)

137-140: LGTM! Enhancement PR validation correctly extended.

The validation logic now accepts OVN Kubernetes enhancement PRs as a valid source, following the same pattern as OpenShift and Kubernetes enhancements. The error message appropriately documents all three accepted formats.

features.md (1)

14-14: LGTM! Documentation accurately reflects the NetworkConnect feature gate.

The feature gate is correctly documented as enabled in DevPreviewNoUpgrade for both Hypershift and SelfManagedHA profiles, consistent with the implementation.

payload-manifests/featuregates/featureGate-SelfManagedHA-OKD.yaml (1)

173-175: LGTM! NetworkConnect correctly disabled in SelfManagedHA-OKD.

The feature gate is appropriately added to the disabled list for the OKD feature set, consistent with the feature gate configuration documented in features.md.

payload-manifests/featuregates/featureGate-SelfManagedHA-TechPreviewNoUpgrade.yaml (1)

47-49: LGTM! NetworkConnect correctly disabled in SelfManagedHA-TechPreviewNoUpgrade.

The feature gate is appropriately added to the disabled list for the TechPreviewNoUpgrade feature set, consistent with the documented configuration.

payload-manifests/featuregates/featureGate-Hypershift-TechPreviewNoUpgrade.yaml (1)

44-46: LGTM! NetworkConnect correctly disabled in Hypershift-TechPreviewNoUpgrade.

The feature gate is appropriately added to the disabled list for the TechPreviewNoUpgrade feature set, consistent with the feature gate configuration.

payload-manifests/featuregates/featureGate-Hypershift-OKD.yaml (1)

170-172: LGTM! NetworkConnect correctly disabled in Hypershift-OKD.

The feature gate is appropriately added to the disabled list for the OKD feature set, consistent with the documented feature gate configuration.

payload-manifests/featuregates/featureGate-SelfManagedHA-Default.yaml (1)

171-173: LGTM! NetworkConnect correctly disabled in SelfManagedHA-Default.

The feature gate is appropriately added to the disabled list for the Default feature set, consistent with the feature gate configuration where NetworkConnect is only enabled in DevPreviewNoUpgrade.

payload-manifests/featuregates/featureGate-Hypershift-Default.yaml (1)

168-170: LGTM! NetworkConnect correctly disabled in Hypershift-Default.

The feature gate is appropriately added to the disabled list for the Default feature set, consistent with the feature gate configuration where NetworkConnect is only enabled in DevPreviewNoUpgrade.

payload-manifests/featuregates/featureGate-SelfManagedHA-DevPreviewNoUpgrade.yaml (1)

247-249: LGTM!

The NetworkConnect feature gate is correctly added to the enabled list in proper alphabetical order with valid JSON structure.

payload-manifests/featuregates/featureGate-Hypershift-DevPreviewNoUpgrade.yaml (1)

265-267: LGTM!

The NetworkConnect feature gate is correctly added to the enabled list in proper alphabetical order with valid JSON structure, consistent with the SelfManagedHA configuration.

features/features.go (1)

190-196: Confirm the enhancement PR location is intentional.

The enhancement PR (ovn-kubernetes/ovn-kubernetes#5246) is valid and merged, with content directly related to the NetworkConnect feature ("OKEP for Connecting UDNs"). However, it deviates from the established pattern in this file—other feature gates reference openshift/enhancements or kubernetes/enhancements repositories. Verify this ovn-kubernetes PR is the intended reference rather than an equivalent proposal in openshift/enhancements.

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.5.0)

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 and usage tips.}

[JoelSpeed]

@tssurya This is a new one on me (OKEP), the gate name you've chosen here, it's not going to be used at all by the OVN or upstream K8s systems right? If there is any overlap, we've had some issues in the past and I suggest we choose a downstream specific name for the downstream specific parts.

Speaking of, is there anything downstream specific? Do we need an OCP EP to show how this upstream feature will be integrated into OCP or is it really a completely upstream feature?

[tssurya]

@tssurya This is a new one on me (OKEP), the gate name you've chosen here, it's not going to be used at all by the OVN or upstream K8s systems right? If there is any overlap, we've had some issues in the past and I suggest we choose a downstream specific name for the downstream specific parts.

Hi Joel! good question, no its not the same name - in ovnk we still don't have fancy feature CRDs :D we are old school gating using bool flags (me cringes) so its called --network-connect-enable (nce) flag via CLI passed when deploying the networking binary. So this feature gate I add is specific to only OCP and in CNO we will translate this logic to in turn - go and pass that CLI flag when it kicks in the binary to start running ovnkube

https://ovn-kubernetes.io/okeps/okep-5085-localnet-api/ is where we have our OKEPs published. This feature is: https://ovn-kubernetes.io/okeps/okep-5224-connecting-udns/okep-5224-connecting-udns/

Speaking of, is there anything downstream specific? Do we need an OCP EP to show how this upstream feature will be integrated into OCP or is it really a completely upstream feature?

Also a good question! There is nothing specific to OCP that warrants an OCP EP except for the feature gate we add and a small PR to enable the feature via CNO. The feature is completely an upstream feature E2E and easily pluggable to the point where if this gate is off, then the controller is just totally OFF in ovnkube and feature code does nothing. Upgrades in OCP will also be seamless and no extra thing to consider. I had thought about this if we needed a downstream specific enhancement and given nothing needed to be specially d/s didn't do one.
Even tests, I plan to leverage the OTE framework and simply run the upstream tests in OCP CI. So nothing to be added in origin. No need for new jobs in release either when lifting FG.

[JoelSpeed]

Hi Joel! good question, no its not the same name - in ovnk we still don't have fancy feature CRDs :D we are old school gating using bool flags (me cringes) so its called --network-connect-enable (nce) flag via CLI passed when deploying the networking binary. So this feature gate I add is specific to only OCP and in CNO we will translate this logic to in turn - go and pass that CLI flag when it kicks in the binary to start running ovnkube

Makes sense to me, thanks for the explanation

Also a good question! There is nothing specific to OCP that warrants an OCP EP except for the feature gate we add and a small PR to enable the feature via CNO. The feature is completely an upstream feature E2E and easily pluggable to the point where if this gate is off, then the controller is just totally OFF in ovnkube and feature code does nothing. Upgrades in OCP will also be seamless and no extra thing to consider. I had thought about this if we needed a downstream specific enhancement and given nothing needed to be specially d/s didn't do one.
Even tests, I plan to leverage the OTE framework and simply run the upstream tests in OCP CI. So nothing to be added in origin. No need for new jobs in release either when lifting FG.

Also makes sense, thanks for taking the time to explain

/lgtm

[openshift-ci-robot]

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/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]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JoelSpeed

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 [JoelSpeed]

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

[openshift-ci]

@tssurya: 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/okd-scos-images	5964209	link	true	/test okd-scos-images
ci/prow/e2e-aws-ovn-hypershift	5964209	link	true	/test e2e-aws-ovn-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.