operator/v1: replace anyOf with CEL XValidation for maxConnections

[asadawar]

Summary

• Replace anyOf OpenAPI schema validation with CEL XValidation rule for IngressControllerTuningOptions.maxConnections
• The anyOf pattern (enum [-1, 0] OR range [2000, 2000000]) produced incomplete error messages when both branches failed: the API server only reported "must be one of: -1, 0", omitting the valid range
• The new CEL rule produces a clear, unified error message: "maxConnections must be 0, -1, or between 2000 and 2000000"
• Add 8 onCreate tests (valid and invalid values) and 3 onUpdate ratcheting tests

Before (anyOf error)

spec.tuningOptions: Invalid value: "object": spec.tuningOptions in body
must validate at least one schema (anyOf)
spec.tuningOptions.maxConnections: Unsupported value: 500:
supported values: "-1", "0"

After (CEL error)

spec.tuningOptions.maxConnections: Invalid value: "integer":
maxConnections must be 0, -1, or between 2000 and 2000000

Context

The original anyOf was added in PR #1161 (April 2022) before CEL XValidation was widely adopted in this repo. The file now has 30 XValidation rules, including 3 on the adjacent httpKeepAliveTimeout field in the same struct. CEL and OpenAPI structural validation ratchet identically under CRDValidationRatcheting (GA since Kubernetes 1.30), so there is no behavioral change for existing stored objects.

Test plan

• make update (full codegen) completes successfully
• Integration tests pass (make -C tests test), including:
  • Valid values: -1, 2000, 50000, 2000000
  • Invalid values: 1, 500, 1999, 3000000
  • Ratcheting: update invalid to valid, update invalid to another invalid (rejected), retain invalid while updating other fields (ratcheted)
• anyOf removed from all 5 generated CRD variants (Default, CustomNoUpgrade, DevPreviewNoUpgrade, TechPreviewNoUpgrade, OKD)
• CEL XValidation rule present in all 5 generated CRD variants

Bug: https://issues.redhat.com/browse/OCPBUGS-86570

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

Hello @asadawar! 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.

[openshift-ci]

Hi @asadawar. 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]

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: 524308db-a99e-4804-99c3-24f57f1f784c

📥 Commits

Reviewing files that changed from the base of the PR and between 751d5ed and f39490c.

⛔ Files ignored due to path filters (8)

• operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-CustomNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
• operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-Default.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
• operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-DevPreviewNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
• operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-OKD.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
• operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-TechPreviewNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
• operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml is excluded by !**/zz_generated.featuregated-crd-manifests/**
• operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/IngressControllerDynamicConfigurationManager.yaml is excluded by !**/zz_generated.featuregated-crd-manifests/**
• operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/TLSGroupPreferences.yaml is excluded by !**/zz_generated.featuregated-crd-manifests/**

📒 Files selected for processing (3)

• operator/v1/manual-override-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml
• operator/v1/tests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml
• operator/v1/types_ingress.go

💤 Files with no reviewable changes (1)

• operator/v1/manual-override-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml

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

• operator/v1/types_ingress.go
• operator/v1/tests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml

---

📝 Walkthrough

Walkthrough

This PR adds validation constraints for the MaxConnections field in IngressControllerTuningOptions by introducing a CEL-based XValidation rule in the Go type definition that restricts values to 0, -1, or the range 2000–2000000. The corresponding OpenAPI schema constraints are removed from the CRD manifest. Test coverage is added for both onCreate and onUpdate scenarios, verifying acceptance of valid values, rejection of invalid values with appropriate error messages, and field ratcheting behavior.

🚥 Pre-merge checks | ✅ 15

✅ Passed checks (15 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: replacing anyOf OpenAPI schema validation with CEL XValidation for the maxConnections field.
Description check	✅ Passed	The description comprehensively explains the change, rationale, technical context, error message improvements, test coverage, and bug reference—all directly related to the changeset.
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	All 11 new test names in the PR are stable and deterministic, using descriptive static strings with no generated identifiers, timestamps, UUIDs, node names, or dynamic namespaces. Numeric values in...
Test Structure And Quality	✅ Passed	Tests follow Ginkgo quality requirements: single responsibility per test, proper setup/cleanup via framework BeforeEach/AfterEach with OncePerOrdered semantics, 5s timeouts on all cluster operation...
Microshift Test Compatibility	✅ Passed	This PR adds CRD schema validation tests (YAML format, not Ginkgo e2e tests). The custom check applies only to Ginkgo e2e tests (It(), Describe(), etc.), which this PR does not contain.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	PR adds no Ginkgo e2e tests; only CRD validation tests in YAML format and kubebuilder schema constraints. Custom check for SNO-incompatible e2e tests is not applicable.
Topology-Aware Scheduling Compatibility	✅ Passed	PR only modifies CRD validation rules for maxConnections (HAProxy tuning), not deployment manifests, controllers, or scheduling constraints. No topology-assuming logic introduced.
Ote Binary Stdout Contract	✅ Passed	PR only modifies types comments, CRD YAML configuration, and test YAML cases—no executable code writes to stdout at process level.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	The PR adds 8 onCreate and 3 onUpdate Ginkgo e2e tests for maxConnections validation. These tests contain no hardcoded IPv4 addresses, IPv4-only logic, or external connectivity requirements. Tests...
No-Weak-Crypto	✅ Passed	PR does not modify cryptographic code. Changes are limited to API validation rules for numeric field (maxConnections) using CEL XValidation, test cases, and YAML manifest updates.
Container-Privileges	✅ Passed	PR modifies CRD schemas and validation rules only; no container/K8s deployment manifests with privileged settings, hostPID/hostNetwork/hostIPC, SYS_ADMIN capabilities, or allowPrivilegeEscalation d...
No-Sensitive-Data-In-Logs	✅ Passed	PR contains no logging statements or exposure of sensitive data. Changes involve only field validation rules and test cases with non-sensitive numeric values.

_{✏️ 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)

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

---

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

[coderabbitai]

🧹 Nitpick comments (1)

operator/v1/tests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml (1)

681-812: ⚡ Quick win

Consider adding test coverage for maxConnections: 0.

The CEL rule on line 2037 of operator/v1/types_ingress.go explicitly allows self == 0, and the field documentation states that 0 is a permitted value (treated as default). While the current tests comprehensively cover -1, the valid range boundaries (2000, 2000000), mid-range values (50000), and various invalid values, there is no explicit test verifying that maxConnections: 0 is accepted.

Adding a test case for this edge value would complete the coverage of all documented permitted values.

🤖 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 `@operator/v1/tests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml`
around lines 681 - 812, Add a test case that verifies maxConnections: 0 is
accepted — create a new test entry (e.g. name "Should be able to create an
IngressController with maxConnections of 0") modeled after the existing valid
cases (like the -1 and 2000 cases) with an initial YAML containing
spec.tuningOptions.maxConnections: 0 and an expected YAML that includes the
defaulted policies (httpEmptyRequestsPolicy, idleConnectionTerminationPolicy,
closedClientConnectionPolicy) and tuningOptions.maxConnections: 0; this will
exercise the CEL rule referenced in types_ingress.go that allows self == 0 and
complete coverage of permitted values.

🤖 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 `@operator/v1/tests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml`:
- Around line 681-812: Add a test case that verifies maxConnections: 0 is
accepted — create a new test entry (e.g. name "Should be able to create an
IngressController with maxConnections of 0") modeled after the existing valid
cases (like the -1 and 2000 cases) with an initial YAML containing
spec.tuningOptions.maxConnections: 0 and an expected YAML that includes the
defaulted policies (httpEmptyRequestsPolicy, idleConnectionTerminationPolicy,
closedClientConnectionPolicy) and tuningOptions.maxConnections: 0; this will
exercise the CEL rule referenced in types_ingress.go that allows self == 0 and
complete coverage of permitted values.

---

ℹ️ Review info

⚙️ Run configuration

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

Review profile: CHILL

Plan: Enterprise

Run ID: 9937caba-83df-49ba-9bad-95689ab5e295

📥 Commits

Reviewing files that changed from the base of the PR and between efa7fe9 and 751d5ed.

⛔ Files ignored due to path filters (7)

• operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-CustomNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
• operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-Default.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
• operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-DevPreviewNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
• operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-OKD.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
• operator/v1/zz_generated.crd-manifests/0000_50_ingress_00_ingresscontrollers-TechPreviewNoUpgrade.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
• operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml is excluded by !**/zz_generated.featuregated-crd-manifests/**
• operator/v1/zz_generated.featuregated-crd-manifests/ingresscontrollers.operator.openshift.io/IngressControllerDynamicConfigurationManager.yaml is excluded by !**/zz_generated.featuregated-crd-manifests/**

📒 Files selected for processing (3)

• operator/v1/manual-override-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml
• operator/v1/tests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml
• operator/v1/types_ingress.go

💤 Files with no reviewable changes (1)

• operator/v1/manual-override-crd-manifests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml

[JoelSpeed]

/ok-to-test

CC @Miciah

This LGTM but would like Miciah to ack

[asadawar]

The verify-crd-schema and verify-crdify failures are expected. Removing the anyOf from the manual override removes the structural schema entry for tuningOptions.maxConnections, which the crd-schema-checker flags as NoFieldRemoval.

This is the same pattern as PR #2837, where the approver used /override ci/prow/verify-crd-schema and /override ci/prow/verify-crdify to bypass these checks for an intentional API schema change.

Why the anyOf must be removed (not kept alongside CEL):

When both anyOf and CEL XValidation are present, the API server short-circuits on the anyOf structural validation failure and never evaluates the CEL rule. The error message remains:

"spec.tuningOptions" must validate at least one schema (anyOf)
spec.tuningOptions.maxConnections: Unsupported value: 500: supported values: "-1", "0"
some validation rules were not checked because the object was invalid

The CEL error message never appears. The only way to get a clear error message is to remove the anyOf and let CEL handle the validation.

The integration test failure is likely a cascading effect from the schema change. All integration tests pass locally with make -C tests test.

[Miciah]

Thanks! Nice simplification, using CEL to replace the override patch.

/lgtm

[openshift-merge-bot]

Pipeline controller notification

No second-stage tests were triggered for this PR.

This can happen when:

• The changed files don't match any pipeline_run_if_changed patterns
• All files match pipeline_skip_if_only_changed patterns
• No pipeline-controlled jobs are defined for the master branch

Use /test ? to see all available tests.

[Miciah]

/assign

[JoelSpeed]

/lgtm
/verified by integration testing

[openshift-ci-robot]

@JoelSpeed: This PR has been marked as verified by integration testing.

Details

In response to this:

/lgtm
/verified by integration testing

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]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JoelSpeed, Miciah

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

[asadawar]

@JoelSpeed @Miciah All 3 CI failures here share the same root cause and are expected:

1. verify-crd-schema - NoFieldRemoval: removing the anyOf from the manual override drops the structural schema entry for tuningOptions.maxConnections
2. verify-crdify - Type change: tuningOptions goes from implicit type to explicit type: object (appears once per feature gate CRD variant)
3. verify - cascading from the same schema change

This is the same pattern as PR #2837, where the approver overrode verify-crd-schema and verify-crdify for an intentional API schema change. The anyOf must be removed (not kept alongside CEL) because structural validation runs before CEL and rejects the sentinel values before CEL can evaluate them.

Could you please override these checks?

/override ci/prow/verify
/override ci/prow/verify-crd-schema
/override ci/prow/verify-crdify

[openshift-ci]

@asadawar: asadawar unauthorized: /override is restricted to Repo administrators, approvers in top level OWNERS file, and the following github teams:openshift: openshift-release-oversight openshift-staff-engineers openshift-sustaining-engineers.

Details

In response to this:

@JoelSpeed @Miciah All 3 CI failures here share the same root cause and are expected:

1. verify-crd-schema - NoFieldRemoval: removing the anyOf from the manual override drops the structural schema entry for tuningOptions.maxConnections
2. verify-crdify - Type change: tuningOptions goes from implicit type to explicit type: object (appears once per feature gate CRD variant)
3. verify - cascading from the same schema change

This is the same pattern as PR #2837, where the approver overrode verify-crd-schema and verify-crdify for an intentional API schema change. The anyOf must be removed (not kept alongside CEL) because structural validation runs before CEL and rejects the sentinel values before CEL can evaluate them.

Could you please override these checks?

/override ci/prow/verify
/override ci/prow/verify-crd-schema
/override ci/prow/verify-crdify

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.

[openshift-merge-bot]

/retest-required

Remaining retests: 0 against base HEAD 449a253 and 2 for PR HEAD 751d5ed in total

[openshift-merge-bot]

/retest-required

Remaining retests: 0 against base HEAD 1ad2ac3 and 1 for PR HEAD 751d5ed in total

[openshift-merge-bot]

/retest-required

Remaining retests: 0 against base HEAD 332af6b and 0 for PR HEAD 751d5ed in total

[openshift-merge-bot]

/hold

Revision 751d5ed was retested 3 times: holding

[asadawar]

@JoelSpeed @Miciah can you PTAL when you have a moment?

[JoelSpeed]

@asadawar verify is failing because your code generation is out of date. Please rebase this PR on the latest main and re-run the code generation steps

[openshift-ci]

New changes are detected. LGTM label has been removed.

[asadawar]

@JoelSpeed Thanks for checking this. Rebased on latest master and re-ran codegen. The TLSGroupPreferences CRD variant was added since the original commit and now includes the CEL rule. verify should pass now.

[openshift-ci]

@asadawar: 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/verify-crdify	f39490c	link	true	/test verify-crdify
ci/prow/verify-crd-schema	f39490c	link	true	/test verify-crd-schema

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.