Skip to content

[SREP-3696] Run the egress verifier in pod mode on HCP clusters#858

Merged
openshift-merge-bot[bot] merged 1 commit intoopenshift:masterfrom
gvnnn:SREP-3696
Mar 9, 2026
Merged

[SREP-3696] Run the egress verifier in pod mode on HCP clusters#858
openshift-merge-bot[bot] merged 1 commit intoopenshift:masterfrom
gvnnn:SREP-3696

Conversation

@gvnnn
Copy link
Contributor

@gvnnn gvnnn commented Mar 6, 2026

Enforce pod mode if the cluster is HCP, regardless of whether --pod-mode was provided on the command line.
Also verify if any of the conflicting command line flags are provided after flag parsing to ensure we're comparing against the current run mode.

In the future this change might be moved to a dedicated code path, independent of input/flag validation.

Summary by CodeRabbit

  • New Features

    • Pod mode is now automatically enabled for hypershift-enabled clusters.
  • Bug Fixes

    • Validation now detects and prevents incompatible cloud-provider flags from being used with Pod mode, with clearer error messages.
  • Tests

    • Added tests covering multiple Pod-mode compatibility scenarios to ensure validation behavior.

@openshift-ci openshift-ci bot requested review from iamkirkbater and zmird-r March 6, 2026 14:14
@coderabbitai
Copy link

coderabbitai bot commented Mar 6, 2026

Walkthrough

Adds runtime validation for Pod mode by introducing validatePodModeCompatibility(), forces Pod mode for hypershift-enabled clusters in Run, and removes setup-time mutual exclusivity between Pod mode and certain cloud-provider flags; errors are returned when incompatible flags are set with Pod mode.

Changes

Cohort / File(s) Summary
Pod Mode Validation Logic
cmd/network/verification.go
Removed mutual-exclusion constraints between Pod mode and cloud-specific flags in command setup. In Run, force-enabled Pod mode when the cluster is hypershift-enabled and invoked a post-parse validatePodModeCompatibility() check. Added func (e *EgressVerification) validatePodModeCompatibility() error which, when Pod mode is true, detects and reports incompatible flags: --cacert, --subnet-id, --security-group, --all-subnets, non-default --cpu-arch, --gcp-project-id, and --vpc.
Pod Mode Compatibility Tests
cmd/network/verification_pod_mode_test.go
Added TestValidatePodModeCompatibility with multiple scenarios asserting errors or no-errors for combinations of Pod mode and the above cloud-provider flags.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
Test Structure And Quality ⚠️ Warning The test file shows inconsistent assertion message patterns. Early tests include meaningful messages, but TestValidatePodModeCompatibility lacks them on lines 522, 524, and 527, breaking the established codebase pattern. Add meaningful failure messages to all assertions in TestValidatePodModeCompatibility to align with patterns demonstrated elsewhere in the same file.
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'Run the egress verifier in pod mode on HCP clusters' directly and clearly summarizes the main change: enforcing pod mode for the egress verifier on HCP clusters.
Stable And Deterministic Test Names ✅ Passed All test names in cmd/network/verification_pod_mode_test.go are stable and deterministic, containing only descriptive static strings with no dynamic elements.

✏️ 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

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.

❤️ Share

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

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (2)
cmd/network/verification_pod_mode_test.go (2)

437-444: Misleading errorMsg field in test case.

The errorMsg is set to "--ca-cert" but wantError is false. Since errorMsg is only checked when wantError is true, this is dead code and could confuse future readers.

🔧 Suggested fix
 		{
 			name: "non_pod_mode",
 			ev: &EgressVerification{
 				PodMode: false,
 			},
 			wantError: false,
-			errorMsg:  "--ca-cert",
 		},
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@cmd/network/verification_pod_mode_test.go` around lines 437 - 444, The test
case named "non_pod_mode" in the table of tests for EgressVerification sets
wantError=false but still provides an errorMsg of "--ca-cert", which is
dead/confusing; remove the errorMsg value (or set it to an empty string) for
that test case (the struct literal with name "non_pod_mode" and ev:
&EgressVerification{PodMode: false}) so only failing cases include errorMsg and
readers aren’t misled.

430-531: Missing test case for pod mode happy path.

The test cases cover various conflicting flag scenarios, but there's no test case verifying that pod mode enabled with no conflicting flags returns no error. Adding this would ensure the happy path is explicitly covered.

🧪 Suggested test case to add
 	tests := []struct {
 		name      string
 		ev        *EgressVerification
 		wantError bool
 		errorMsg  string
 	}{
+		{
+			name: "pod_mode_no_conflicts",
+			ev: &EgressVerification{
+				PodMode: true,
+			},
+			wantError: false,
+		},
 		{
 			name: "non_pod_mode",
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@cmd/network/verification_pod_mode_test.go` around lines 430 - 531, Add a test
case to TestValidatePodModeCompatibility that verifies the pod-mode happy path:
create an entry named like "pod_mode_happy_path" with ev set to
&EgressVerification{PodMode: true} (no CaCert, SubnetIds, SecurityGroupId,
AllSubnets, CpuArchName, GcpProjectID, VpcName) and wantError: false, then the
existing loop will call ev.validatePodModeCompatibility() and assert no error;
this uses the existing EgressVerification struct and
validatePodModeCompatibility method so it fits into the current test table.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@cmd/network/verification.go`:
- Around line 239-242: The code dereferences e.cluster without checking for nil
when running without --cluster-id, causing a panic in the block that reads
e.cluster.Hypershift().Enabled(); fix by guarding that access — only call
e.cluster.Hypershift().Enabled() (and run the e.log.Info/PodMode assignment)
when e.cluster is non-nil (or ensure fetchCluster() sets e.cluster); update the
conditional around PodMode (the block that references e.cluster, Hypershift(),
Enabled(), e.log.Info and PodMode) to perform a nil-check on e.cluster before
calling its methods so the command works when no cluster-id is provided.

---

Nitpick comments:
In `@cmd/network/verification_pod_mode_test.go`:
- Around line 437-444: The test case named "non_pod_mode" in the table of tests
for EgressVerification sets wantError=false but still provides an errorMsg of
"--ca-cert", which is dead/confusing; remove the errorMsg value (or set it to an
empty string) for that test case (the struct literal with name "non_pod_mode"
and ev: &EgressVerification{PodMode: false}) so only failing cases include
errorMsg and readers aren’t misled.
- Around line 430-531: Add a test case to TestValidatePodModeCompatibility that
verifies the pod-mode happy path: create an entry named like
"pod_mode_happy_path" with ev set to &EgressVerification{PodMode: true} (no
CaCert, SubnetIds, SecurityGroupId, AllSubnets, CpuArchName, GcpProjectID,
VpcName) and wantError: false, then the existing loop will call
ev.validatePodModeCompatibility() and assert no error; this uses the existing
EgressVerification struct and validatePodModeCompatibility method so it fits
into the current test table.

ℹ️ Review info
⚙️ Run configuration

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

Review profile: CHILL

Plan: Pro

Run ID: 7b5143d3-40b0-4c28-b29a-101c30331eb7

📥 Commits

Reviewing files that changed from the base of the PR and between 76b8070 and ec2ce23.

📒 Files selected for processing (2)
  • cmd/network/verification.go
  • cmd/network/verification_pod_mode_test.go

@gvnnn
Copy link
Contributor Author

gvnnn commented Mar 6, 2026

/hold

@openshift-ci openshift-ci bot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 6, 2026
@gvnnn gvnnn changed the title Run the egress verifier in pod mode on HCP clusters [SREP-3696] Run the egress verifier in pod mode on HCP clusters Mar 6, 2026
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

♻️ Duplicate comments (1)
cmd/network/verification.go (1)

239-242: ⚠️ Potential issue | 🔴 Critical

Still need the nil guard before HCP detection.

e.cluster is still nil on the supported no---cluster-id path, so e.cluster.Hypershift().Enabled() can panic before the new pod-mode compatibility validation runs.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@cmd/network/verification.go` around lines 239 - 242, The code checks
e.cluster.Hypershift().Enabled() without verifying e.cluster is non-nil which
can panic on the no---cluster-id path; update the block that sets e.PodMode (the
if that currently reads if !e.PodMode && e.cluster.Hypershift().Enabled()) to
first guard that e.cluster != nil (and only then call
e.cluster.Hypershift().Enabled()), keeping the log and assignment to e.PodMode
as-is; ensure the nil-check is performed before invoking Hypershift() or
Enabled() to avoid nil dereference.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@cmd/network/verification.go`:
- Around line 811-813: The code incorrectly marks "--cacert" as incompatible by
appending it to conflicts when e.CaCert is set; remove that classification so
the CA bundle is allowed in pod-mode. Specifically, delete (or stop executing)
the if block that checks e.CaCert and appends "--cacert" to the conflicts slice
(the e.CaCert check and conflicts = append(conflicts, "--cacert") line) so that
defaultValidateEgressInput() can continue to load the CA bundle into the proxy
config for pod-mode runs.
- Around line 827-829: The check using e.CpuArchName only detects the final
value and cannot tell if the user explicitly passed --cpu-arch; replace that
pattern with a Cobra Flag.Changed check: lookup the "cpu-arch" flag on
validateEgressCmd (e.g., validateEgressCmd.Flags().Lookup("cpu-arch")), ensure
the flag is non-nil and flag.Changed is true, and only then append "--cpu-arch"
to conflicts instead of relying on e.CpuArchName; this mirrors how other flags
in this function detect explicit usage.

---

Duplicate comments:
In `@cmd/network/verification.go`:
- Around line 239-242: The code checks e.cluster.Hypershift().Enabled() without
verifying e.cluster is non-nil which can panic on the no---cluster-id path;
update the block that sets e.PodMode (the if that currently reads if !e.PodMode
&& e.cluster.Hypershift().Enabled()) to first guard that e.cluster != nil (and
only then call e.cluster.Hypershift().Enabled()), keeping the log and assignment
to e.PodMode as-is; ensure the nil-check is performed before invoking
Hypershift() or Enabled() to avoid nil dereference.

ℹ️ Review info
⚙️ Run configuration

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

Review profile: CHILL

Plan: Pro

Run ID: f9ad0983-f3cb-42b9-aa06-1bfdf65524b0

📥 Commits

Reviewing files that changed from the base of the PR and between ec2ce23 and e594ef9.

📒 Files selected for processing (2)
  • cmd/network/verification.go
  • cmd/network/verification_pod_mode_test.go
🚧 Files skipped from review as they are similar to previous changes (1)
  • cmd/network/verification_pod_mode_test.go

@gvnnn
Copy link
Contributor Author

gvnnn commented Mar 6, 2026

/hold cancel

@openshift-ci openshift-ci bot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Mar 6, 2026
@bergmannf
Copy link
Contributor

/lgtm
/approve

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Mar 9, 2026
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 9, 2026

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bergmannf, gvnnn

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:

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

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 9, 2026
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 9, 2026

@gvnnn: 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.

@openshift-merge-bot openshift-merge-bot bot merged commit 86e295a into openshift:master Mar 9, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants