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: 5420a102-cd1d-4077-8d68-da0c86afdb35

📥 Commits

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

⛔ 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_ingresscontroller.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 (1)

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

---

📝 Walkthrough

Walkthrough

A CEL XValidation rule is added to the MaxConnections field in types_ingresscontroller.go, restricting accepted values to 0, -1, or the inclusive range 2000–2000000. The previously equivalent anyOf OpenAPI schema block under spec.logging.access.destination.syslog.tuningOptions.maxConnections in the manual-override CRD manifest is removed. New test cases are added covering onCreate acceptance and rejection, onUpdate valid and invalid transitions, and ratcheting behavior.

🚥 Pre-merge checks | ✅ 15

✅ Passed checks (15 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title precisely describes the main change: replacing anyOf OpenAPI validation with CEL XValidation for the maxConnections field, which is the core objective.
Description check	✅ Passed	The description comprehensively explains the rationale (fixing incomplete error messages), technical approach (CEL XValidation instead of anyOf), test coverage, and behavioral guarantees under CRDValidationRatcheting.
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 maxConnections Ginkgo test names in the YAML test file are stable and deterministic. They contain no dynamic values like pods with generated suffixes, timestamps, UUIDs, node names, name...
Test Structure And Quality	✅ Passed	Tests follow the repository's declarative YAML pattern with auto-generated Ginkgo table tests. All 5 quality requirements met: (1) single responsibility—each test validates one behavior; (2) setup/...
Microshift Test Compatibility	✅ Passed	This PR does not add any Ginkgo e2e tests. The test file modified (operator/v1/tests/ingresscontrollers.operator.openshift.io/AAA_ungated.yaml) contains CRD validation test fixtures in YAML format,...
Single Node Openshift (Sno) Test Compatibility	✅ Passed	PR adds no Ginkgo e2e tests; only modifies CRD manifests and adds YAML validation test specs for IngressController API field constraints.
Topology-Aware Scheduling Compatibility	✅ Passed	PR changes only CRD validation schema for maxConnections field (anyOf → CEL XValidation). No deployment manifests, operator code, or scheduling constraints (affinity, topology spread, PDB, etc.) ar...
Ote Binary Stdout Contract	✅ Passed	PR contains only YAML manifest/test data and Kubebuilder metadata tags; no executable process-level code that could write to stdout.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	Tests added are CRD validation specs in YAML format with no IPv4 hardcoding, IPv4-only assumptions, or external connectivity requirements. They only validate IngressController spec fields locally w...
No-Weak-Crypto	✅ Passed	PR contains no weak cryptographic algorithms, custom crypto implementations, or insecure secret/token comparisons. Changes are limited to validation schema refactoring for an integer configuration...
Container-Privileges	✅ Passed	PR contains no container or Kubernetes workload manifests with privileged settings. Changes are limited to CRD schema definitions and validation rules for IngressControllerTuningOptions.maxConnecti...
No-Sensitive-Data-In-Logs	✅ Passed	PR makes validation schema changes only. No logging functions, imports, or sensitive data logging statements are added or modified.

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

[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

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

[asadawar]

verify passes now. verify-crd-schema and verify-crdify fail as expected (intentional anyOf removal, same pattern as #2837)
@JoelSpeed @Miciah - Ready for your review/feedback. Thanks

[JoelSpeed]

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

[JoelSpeed]

/hold cancel

[openshift-ci]

@JoelSpeed: Overrode contexts on behalf of JoelSpeed: ci/prow/verify-crd-schema, ci/prow/verify-crdify

Details

In response to this:

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

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]

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.

[asadawar]

@JoelSpeed rebased again on latest master and re-ran codegen. The repo is moving fast so this keeps going stale. Could you override the two expected failures and merge when you get a chance? The verify check passes now.

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

[openshift-ci]

New changes are detected. LGTM label has been removed.

[openshift-ci]

@asadawar: you cannot LGTM your own PR.

Details

In response to this:

@JoelSpeed rebased again on latest master and re-ran codegen. The repo is moving fast so this keeps going stale. Could you override the two expected failures and merge when you get a chance? The verify check passes now.

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

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

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: asadawar, 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

[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 rebased again on latest master and re-ran codegen. The repo is moving fast so this keeps going stale. Could you override the two expected failures and merge when you get a chance? The verify check passes now.

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

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

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: asadawar, 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

[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	ff87804	link	true	/test verify-crdify
ci/prow/verify-crd-schema	ff87804	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.