fix(e2e): wait for DNSNameResolver ready before CNP connectivity checks

[oilbeater]

Summary

• Add waitForDNSResolversReady() helper to explicitly wait for DNSNameResolver CRs to have resolved addresses before running connectivity checks, fixing flaky CNP domain e2e test
• Increase default retry parameters from 20×2s to 30×3s as a safety net for slow DNS resolution
• Root cause: when CNP rules are created/updated, OVN ACL address sets may be empty initially since the external dnsnameresolver component needs time to complete the async DNS resolution chain

Test plan

• Run CNP domain e2e test suite multiple times to verify no flaky failures
• Verify waitForDNSResolversReady correctly waits for DNS resolution before connectivity checks
• Confirm existing test behavior is preserved (deny/allow rules still work correctly)

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello @oilbeater, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves an issue with flaky end-to-end tests related to Cluster Network Policies (CNP) and domain-based rules. The core problem stemmed from network connectivity checks occurring before the underlying DNS resolution for domain names was complete, leading to inconsistent test results. The solution ensures that all necessary DNS name resolutions are finalized and address sets are populated before any connectivity assertions are made, thereby stabilizing the test suite and improving its reliability.

Highlights

• Flaky E2E Test Fix: Addressed a flaky CNP domain e2e test by explicitly waiting for DNSNameResolver CRs to resolve addresses before performing connectivity checks.
• DNS Resolution Wait Helper: Introduced a new helper function, waitForDNSResolversReady(), to ensure OVN ACL address sets are populated before network connectivity validations.
• Increased Retry Parameters: Adjusted default retry parameters for connectivity checks from 20x2s to 30x3s, providing a safety net for potentially slow DNS resolution.
• Root Cause Identification: Identified the root cause of flakiness as initially empty OVN ACL address sets when CNP rules are created/updated, due to the asynchronous nature of external DNSNameResolver component's resolution.

Changelog

• test/e2e/cnp-domain/e2e_test.go
  • Imported the k8s.io/apimachinery/pkg/util/wait package.
  • Modified the testNetworkConnectivity function to increase retry attempts and duration for connectivity checks.
  • Added a new helper function waitForDNSResolversReady to poll for DNSNameResolver CRs to have resolved addresses.
  • Integrated calls to waitForDNSResolversReady into various CNP domain test cases to ensure DNS resolution completion before connectivity tests.

Activity

• The pull request description indicates it was generated with Claude Code.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

The pull request effectively addresses the flakiness in CNP domain e2e tests by introducing a waitForDNSResolversReady helper function. This function ensures that DNSNameResolver CRs have resolved addresses before proceeding with connectivity checks, which is crucial for the OVN ACL address sets to be correctly populated. The increase in default retry parameters for network connectivity checks also provides a valuable safety net for scenarios involving slow DNS resolution. These changes significantly improve the reliability and stability of the e2e test suite.

[gemini-code-assist]

Using context.TODO() in wait.PollUntilContextTimeout is a common pattern, but it's generally better practice to use a cancellable context derived from a parent context (e.g., f.Context). This ensures proper context propagation and allows for earlier cancellation if the parent context is cancelled, leading to more robust test behavior.

Suggested change

	err := wait.PollUntilContextTimeout(context.TODO(), 2*time.Second, 60*time.Second, true, func(_ context.Context) (bool, error) {
	err := wait.PollUntilContextTimeout(f.Context, 2*time.Second, 60*time.Second, true, func(_ context.Context) (bool, error) {