Add interval and Infoblox maxResults to ExternalDNS CR

[sanjaytripathi97]

Related issue

• RFE-6781

Customers integrating OpenShift External DNS Operator with Infoblox require two external-dns flags that were not exposed through the ExternalDNS CR:

• --interval — controls how often external-dns synchronizes DNS records (reduces load on Infoblox)
• --infoblox-max-results — sets the _max_results WAPI query parameter, required for Infoblox grids with thousands of DNS records.

Without these, operator-managed deployments only received a fixed set of hardcoded args. Manual patches to the Deployment were reverted on reconcile because the operator owns and reconciles container args.

This blocked successful Infoblox integration in enterprise environments and forced workarounds such as removing ownerReference from the Deployment (operator-unmanaged), which is unsupported and fragile.

With this PR, Expose both settings declaratively via the ExternalDNS CR and wire them through the operator deployment builder.

New CR fields

CR field	external-dns flag	Scope
spec.interval	--interval	All providers
spec.provider.infoblox.maxResults	--infoblox-max-results	Infoblox only
Both fields are optional. When omitted, external-dns uses its defaults (1 minute sync interval; no _max_results on WAPI requests).

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR adds two optional configuration fields to the ExternalDNS CustomResourceDefinition. The Interval field in ExternalDNSSpec allows users to override the default synchronization interval, while the MaxResults field in ExternalDNSInfobloxProviderOptions controls Infoblox WAPI query result limiting. Changes include type definitions for v1alpha1 and v1beta1 API versions, updated CRD schemas, webhook validation to enforce positive values, pod argument generation to surface these settings as container flags, comprehensive unit tests validating argument generation, and example configurations demonstrating usage.

🚥 Pre-merge checks | ✅ 14 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (14 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main changes: adding interval and Infoblox maxResults configuration fields to the ExternalDNS CR.
Description check	✅ Passed	The description is comprehensive and directly related to the changeset, explaining the business rationale (Infoblox integration support), the blocked use case, and the two new CR fields being exposed.
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	All test names in the new pod_interval_test.go are stable, deterministic static strings without dynamic values, timestamps, UUIDs, or other generated identifiers.
Test Structure And Quality	✅ Passed	The PR adds standard Go unit tests (using testing.T), not Ginkgo tests. The custom check is designed to review Ginkgo test code; therefore, it is not applicable to this PR.
Microshift Test Compatibility	✅ Passed	No Ginkgo e2e tests were added in this PR. The only test file added is pod_interval_test.go, which contains standard Go unit tests using testing.T, not Ginkgo e2e tests.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	PR adds two types of tests: pod_interval_test.go with standard Go unit tests (not Ginkgo e2e), and webhook_test.go with Ginkgo tests in envtest environment with zero multi-node assumptions.
Topology-Aware Scheduling Compatibility	✅ Passed	PR adds only CLI arguments (--interval, --infoblox-max-results) to pod containers. No scheduling constraints, affinity rules, or topology-dependent logic are introduced or modified.
Ote Binary Stdout Contract	✅ Passed	PR adds CRD fields, validation, and pod logic with no process-level stdout writes. All code is properly scoped within function bodies; tests have no suite setup; no fmt.Print/klog at module level.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	PR adds only standard Go unit tests (TestIntervalArg, TestInfobloxMaxResultsArg), not Ginkgo e2e tests. Custom check applies only to Ginkgo e2e tests (It(), Describe(), etc.).
No-Weak-Crypto	✅ Passed	PR adds configuration fields for DNS sync interval and Infoblox query parameters with no cryptographic code, custom implementations, or sensitive comparisons detected.
Container-Privileges	✅ Passed	PR adds only command-line flags with no security context modifications. Container remains hardened: privileged=false, runAsNonRoot=true, allowPrivilegeEscalation=false.
No-Sensitive-Data-In-Logs	✅ Passed	No sensitive data logging. New fields (Interval, MaxResults) are non-sensitive operational parameters. No new logging added; existing logs only capture metadata.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ 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)

level=error msg="Running error: context loading failed: failed to load packages: failed to load packages: failed to load with go/packages: err: exit status 1: stderr: go: inconsistent vendoring in :\n\tgithub.com/Azure/azure-sdk-for-go@v60.1.0+incompatible: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\tgithub.com/Azure/go-autorest/autorest@v0.11.27: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\tgithub.com/Azure/go-autorest/autorest/adal@v0.9.20: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\tgithub.com/aws/aws-sdk-go-v2@v1.41.7: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\tgithub.com/aws/aws-sdk-go-v2/config@v1.32.17: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\tgithub.com/aws/aws-sdk-go-v2/credentials@v1.19.16: is explicitly required in go.mod, but not marked as explicit in vendor/module

... [truncated 15600 characters] ...

red in go.mod, but not marked as explicit in vendor/modules.txt\n\tsigs.k8s.io/kustomize/cmd/config@v0.14.2: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\tsigs.k8s.io/kustomize/kyaml@v0.17.2: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\tsigs.k8s.io/randfill@v1.0.0: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\tsigs.k8s.io/structured-merge-diff/v4@v4.6.0: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\tsigs.k8s.io/yaml@v1.4.0: is explicitly required in go.mod, but not marked as explicit in vendor/modules.txt\n\n\tTo ignore the vendor directory, use -mod=readonly or -mod=mod.\n\tTo sync the vendor directory, run:\n\t\tgo mod vendor\n"

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[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 miciah 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

[openshift-ci]

Hi @sanjaytripathi97. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[coderabbitai]

🧹 Nitpick comments (1)

docs/usage.md (1)

213-214: 💤 Low value

Consider clarifying that interval applies to all providers.

The interval field is provider-agnostic and can be used with AWS, GCP, Azure, BlueCat, and Infoblox. Currently it's only documented in the Infoblox example, which may give the impression it's Infoblox-specific. Consider adding a brief note such as "optional, applies to all providers" or showing it in another provider example.

🤖 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 `@docs/usage.md` around lines 213 - 214, Clarify that the interval field is
provider-agnostic by updating the docs: add a short note next to the existing
"interval: 5m" line (or in a shared config section) stating "optional, applies
to all providers (AWS, GCP, Azure, BlueCat, Infoblox)" and/or show the same
interval comment in at least one other provider example so readers don't assume
it's Infoblox-specific; update the text around the example to reference the
global nature of the interval setting and ensure the symbol "interval" and
provider names AWS, GCP, Azure, BlueCat, Infoblox are mentioned.

🤖 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.

Nitpick comments:
In `@docs/usage.md`:
- Around line 213-214: Clarify that the interval field is provider-agnostic by
updating the docs: add a short note next to the existing "interval: 5m" line (or
in a shared config section) stating "optional, applies to all providers (AWS,
GCP, Azure, BlueCat, Infoblox)" and/or show the same interval comment in at
least one other provider example so readers don't assume it's Infoblox-specific;
update the text around the example to reference the global nature of the
interval setting and ensure the symbol "interval" and provider names AWS, GCP,
Azure, BlueCat, Infoblox are mentioned.

---

ℹ️ Review info

⚙️ Run configuration

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

Review profile: CHILL

Plan: Enterprise

Run ID: 2b2c06bf-7b29-4061-b5b4-9062bd77b002

📥 Commits

Reviewing files that changed from the base of the PR and between f97b82d and 8d02f77.

⛔ Files ignored due to path filters (2)

• api/v1alpha1/zz_generated.deepcopy.go is excluded by !**/zz_generated*
• api/v1beta1/zz_generated.deepcopy.go is excluded by !**/zz_generated*

📒 Files selected for processing (8)

• api/v1alpha1/externaldns_types.go
• api/v1beta1/externaldns_types.go
• api/v1beta1/externaldns_webhook.go
• config/crd/bases/externaldns.olm.openshift.io_externaldnses.yaml
• config/samples/infoblox/operator_v1beta1_infoblox_openshift.yaml
• docs/usage.md
• pkg/operator/controller/externaldns/pod.go
• pkg/operator/controller/externaldns/pod_interval_test.go