-
Notifications
You must be signed in to change notification settings - Fork 591
Comments
OCPBUGS-32275: Add ingress.spec.domain immutability validation#2695
OCPBUGS-32275: Add ingress.spec.domain immutability validation #2695grzpiotrowski wants to merge 1 commit intoopenshift:master from
Conversation
Review Summary by Qodo
Add immutability validation for Ingress spec.domain field
🐞 Bug fix
Walkthroughs
Description
• Add immutability validation for spec.domain field in Ingress CRD • Prevent domain changes after initial set to avoid cluster operator degradation • Make domain field optional in validation schema • Add comprehensive test cases for domain immutability behavior
Diagram
flowchart LR
A["Ingress spec.domain"] -->|Add XValidation rule| B["Immutability constraint"]
B -->|oldSelf == '' OR self == oldSelf| C["Allow initial set or no change"]
C -->|Reject domain changes| D["Prevent operator degradation"]
A -->|Make optional| E["Updated CRD schema"]
F["Test cases"] -->|Validate behavior| G["Domain immutability verified"]
File Changes
1. config/v1/types_ingress.go
✨ Enhancement +2/-0
Add domain immutability validation rule
• Add kubebuilder:validation:XValidation rule to enforce domain immutability • Rule allows empty initial value or unchanged domain value • Mark domain field as optional with +optional annotation • Validation message: "domain is immutable once set"
2. openapi/generated_openapi/zz_generated.openapi.go
⚙️ Configuration changes +0/-1
Remove domain from required fields
• Remove domain from required fields list in IngressSpec schema • Makes domain field optional in OpenAPI specification
3. config/v1/tests/ingresses.config.openshift.io/AAA_ungated.yaml
🧪 Tests +57/-0
Add comprehensive domain immutability tests
• Add test for creating Ingress with domain set • Add test for setting domain initially when empty • Add test verifying domain cannot be changed once set with expected error • Add test for updating other fields without changing domainconfig/v1/tests/ingresses.config.openshift.io/AAA_ungated.yaml
(追記) View more (3) (追記ここまで)
4. config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_ingresses.crd.yaml
⚙️ Configuration changes +3/-0
Add domain validation to CRD manifest
• Add x-kubernetes-validations section to domain field • Include validation rule: oldSelf == '' || self == oldSelf • Set validation message: "domain is immutable once set"config/v1/zz_generated.crd-manifests/0000_10_config-operator_01_ingresses.crd.yaml
5. config/v1/zz_generated.featuregated-crd-manifests/ingresses.config.openshift.io/AAA_ungated.yaml
⚙️ Configuration changes +3/-0
Add domain validation to featuregated CRD
• Add x-kubernetes-validations section to domain field • Include validation rule: oldSelf == '' || self == oldSelf • Set validation message: "domain is immutable once set"config/v1/zz_generated.featuregated-crd-manifests/ingresses.config.openshift.io/AAA_ungated.yaml
6. payload-manifests/crds/0000_10_config-operator_01_ingresses.crd.yaml
⚙️ Configuration changes +3/-0
Add domain validation to payload CRD manifest
• Add x-kubernetes-validations section to domain field • Include validation rule: oldSelf == '' || self == oldSelf • Set validation message: "domain is immutable once set"payload-manifests/crds/0000_10_config-operator_01_ingresses.crd.yaml
Code Review by Qodo
🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0)
1. Domain markers undocumented 📘 Rule violation ✓ Correctness
Description
• The Domain field now has +optional and an XValidation immutability rule, but the field comment does not explicitly document optional/omitted behavior or clearly describe the validation behavior in human-readable terms. • This creates an undocumented API constraint for consumers (especially around whether omission vs empty string is allowed and when updates are permitted), which can lead to misunderstanding and incorrect client usage.
Code
config/v1/types_ingress.go[R45-48]// Once set, changing domain is not currently supported. + // +kubebuilder:validation:XValidation:rule="oldSelf == '' || self == oldSelf",message="domain is immutable once set" + // +optional Domain string `json:"domain"`
Evidence
Compliance rule 7 requires that any kubebuilder validation markers and +optional behavior be documented in the field’s Go comment, including what happens when the field is omitted. The Domain field includes +optional and an XValidation rule, but its comment only states immutability at a high level and does not explain omitted/empty behavior or the precise update allowance implied by the CEL expression.
AGENTS.md
config/v1/types_ingress.go[37-48]
Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution ## Issue description The `Domain` field has kubebuilder markers (`+optional` and `+kubebuilder:validation:XValidation`) but the Go field comment does not fully document what those markers mean, including behavior when the field is omitted. ## Issue Context Compliance requires that every kubebuilder validation marker applied to a field be documented in the field comment, including optional vs required behavior (and what happens when omitted), and the meaning/behavior of the validation rule. ## Fix Focus Areas - config/v1/types_ingress.go[37-48]
i Copy this prompt and use it to remediate the issue with your preferred AI generation tools
i The new review experience is currently in Beta. Learn more
This commit fixes OCPBUGS-32275. https://issues.redhat.com/browse/OCPBUGS-32275 Adds `spec.domain` field in the Ingress config CRD validation to make it immutable and match the documentation. Prior to this commit the domain value could be changed and cause degraded state of some cluster operators.
1057ced to
a58ab73
Compare
📝 WalkthroughWalkthroughThis pull request implements immutability validation for the Ingress domain field. The changes include adding a kubebuilder validation annotation to the Domain field in the IngressSpec type definition, updating the CRD schema validation to include x-kubernetes-validations enforcing that the domain field cannot be changed after initial creation, and adding test cases that verify domain immutability behavior and validate the error message when attempting to update the domain. 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this 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
🤖 Fix all issues with AI agents
In `@config/v1/tests/ingresses.config.openshift.io/AAA_ungated.yaml`:
- Around line 26-38: Add a new onUpdate test case named "Should not be able to
set domain if initially empty" that uses an initial Ingress manifest with spec:
{} and an updated manifest that sets spec.domain to apps.example.com, and assert
expectedError: "domain is immutable once set"; place this case alongside the
existing "Should not be able to change domain once set" entry so the suite
verifies the transition from empty→set and ensures the validation rule for
immutability-once-set is covered.
In `@payload-manifests/crds/0000_10_config-operator_01_ingresses.crd.yaml`:
- Around line 132-134: The current validation rule "self == oldSelf" (under
x-kubernetes-validations) prevents any change including setting domain from
empty; update the rule to allow initial population by changing it to something
like "oldSelf.domain == null || oldSelf.domain == '' || self == oldSelf" so the
domain can be set when previously empty but remains immutable afterwards;
alternatively, if domain is always set at creation, simply reword the message to
"domain is immutable" instead of implying an initial set is allowed.
grzpiotrowski
commented
Feb 9, 2026
/test verify
PR-Agent: could not fine a component named verify in a supported language in this PR.
grzpiotrowski
commented
Feb 9, 2026
/jira refresh
openshift-ci-robot
commented
Feb 9, 2026
@grzpiotrowski: This pull request references Jira Issue OCPBUGS-32275, which is invalid:
- expected the bug to target the "4.22.0" version, but no target version was set
Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.
The bug has been updated to refer to the pull request using the external bug tracker.
Details
In response to this:
/jira refresh
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.
grzpiotrowski
commented
Feb 9, 2026
/jira refresh
openshift-ci-robot
commented
Feb 9, 2026
@grzpiotrowski: This pull request references Jira Issue OCPBUGS-32275, which is valid. The bug has been moved to the POST state.
3 validation(s) were run on this bug
- bug is open, matching expected state (open)
- bug target version (4.22.0) matches configured target version for branch (4.22.0)
- bug is in the state ASSIGNED, which is one of the valid states (NEW, ASSIGNED, POST)
Requesting review from QA contact:
/cc @lihongan
Details
In response to this:
/jira refresh
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.
grzpiotrowski
commented
Feb 9, 2026
/jira refresh
openshift-ci-robot
commented
Feb 9, 2026
@grzpiotrowski: An error was encountered querying GitHub for users with public email (hongli@redhat.com) for bug OCPBUGS-32275 on the Jira server at https://issues.redhat.com/. No known errors were detected, please see the full error message for details.
Full error message.
non-200 OK status code: 429 Too Many Requests body: "{\"message\":\"This endpoint is temporarily being throttled. Please try again later. For more on scraping GitHub and how it may affect your rights, please review our Terms of Service (https://docs.github.com/en/site-policy/github-terms/github-terms-of-service)\",\"documentation_url\":\"https://docs.github.com/graphql/using-the-rest-api/rate-limits-for-the-rest-api\",\"status\":\"429\"}"
Please contact an administrator to resolve this issue, then request a bug refresh with /jira refresh.
Details
In response to this:
/jira refresh
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.
lihongan
commented
Feb 10, 2026
/jira refresh
openshift-ci-robot
commented
Feb 10, 2026
@lihongan: This pull request references Jira Issue OCPBUGS-32275, which is valid.
3 validation(s) were run on this bug
- bug is open, matching expected state (open)
- bug target version (4.22.0) matches configured target version for branch (4.22.0)
- bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)
Requesting review from QA contact:
/cc @lihongan
Details
In response to this:
/jira refresh
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.
lihongan
commented
Feb 10, 2026
/retest-required
grzpiotrowski
commented
Feb 10, 2026
Not sure now why the e2e ci jobs don't run. Do they need to be triggered explicitly?
lihongan
commented
Feb 10, 2026
Pre-merge tested and got below
$ oc patch ingress.config cluster --type=merge -p '{"spec":{"domain":"abcd.example.com"}}'
The Ingress "cluster" is invalid: spec.domain: Invalid value: "string": domain is immutable once set
Looks the Invalid value: "string" in error message is inaccurate, the actual invalid value is abcd.example.com right ?
grzpiotrowski
commented
Feb 10, 2026
Pre-merge tested and got below
$ oc patch ingress.config cluster --type=merge -p '{"spec":{"domain":"abcd.example.com"}}' The Ingress "cluster" is invalid: spec.domain: Invalid value: "string": domain is immutable once setLooks the
Invalid value: "string"in error message is inaccurate, the actual invalid value isabcd.example.comright ?
Thank you. I agree it reads a bit confusing, but I don't think this is something configurable and this is a standard output for the +kubebuilder:validation:XValidation. I'm assuming the message is trying to say that there is an invalid string type value and then we provide the custom detailed message domain is immutable once set.
Example: Enforce CRD Immutability with CEL Transition Rules: Immutability upon object creation
candita
commented
Feb 11, 2026
/assign @jcmoraisjr @Thealisyed
jcmoraisjr
commented
Feb 12, 2026
/lgtm
Great job!
openshift-ci-robot
commented
Feb 12, 2026
Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aws-ovn
/test e2e-aws-ovn-hypershift
/test e2e-aws-ovn-hypershift-conformance
/test e2e-aws-ovn-techpreview
/test e2e-aws-serial-1of2
/test e2e-aws-serial-2of2
/test e2e-aws-serial-techpreview-1of2
/test e2e-aws-serial-techpreview-2of2
/test e2e-azure
/test e2e-gcp
/test e2e-upgrade
/test e2e-upgrade-out-of-change
/test minor-e2e-upgrade-minor
everettraven
commented
Feb 12, 2026
/lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the rule is self == OldSelf is immutable but what happens if the domain filed was never empty on an existing cluster? Does that cause a breaking change then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These validations should ratchet.
If the domain field was specified as a non-empty string on an existing cluster, this would take effect and make it so that updates cannot change the field.
Based on the bug this is linked to, that was never supported and causes degradation in the cluster, which means it should generally be OK to tighten this.
Where this would be interesting is if "" is a valid value for this field - which it looks like it might be from an admission standpoint and is something I missed. @grzpiotrowski what happens if the field this validation was added to is set to ""? Should that be able to be modified to set it to a non-empty string?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as a comment from another thread, but copying here for posterity: Do we want to make "" unable to be changed here? What happens today if this field is set to ""?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Domain field is always set by the installer here to a non empty value.
In a scenario that ingress config .spec.domain is "" that's a broken ingress.
The ingress config .spec.domain value is used to set the default .status.domain value on the ingress controller (setDefaultDomain).
The IC .status.domain is validated by the cluster ingress operator and cannot be empty.
From looking at the operator code, if the config value is changed from "" to a valid value the ingress controller would be admitted (operator code). I didn't test that in a cluster.
As a reference, the non-default value which can be set on the ingress controller's .spec.domain field has validation to ensure it is a valid DNS domain name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the analysis here. It seems correct that in practice an empty value here causes degradation in the cluster and should never happen.
I did a bit more investigation here and it looks like Hypershift embeds this type in their APIs: https://github.com/openshift/hypershift/blob/main/api/hypershift/v1beta1/hostedcluster_types.go#L1993
They also do some defaulting behavior when this field is set to "", which means that we probably shouldn't ratchet this with a minimum length as it risks breaking a workflow there.
This change should be OK as-is then. Thanks for helping me verify.
everettraven
commented
Feb 12, 2026
/approve cancel
/lgtm cancel
everettraven
commented
Feb 12, 2026
Prow doesn't seem to like me attempting to remove my approval. Going to add a hold for now until we get my recent question addressed.
/hold
everettraven
commented
Feb 19, 2026
/hold cancel
/lgtm
/approve
openshift-ci-robot
commented
Feb 19, 2026
Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aws-ovn
/test e2e-aws-ovn-hypershift
/test e2e-aws-ovn-hypershift-conformance
/test e2e-aws-ovn-techpreview
/test e2e-aws-serial-1of2
/test e2e-aws-serial-2of2
/test e2e-aws-serial-techpreview-1of2
/test e2e-aws-serial-techpreview-2of2
/test e2e-azure
/test e2e-gcp
/test e2e-upgrade
/test e2e-upgrade-out-of-change
/test minor-e2e-upgrade-minor
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: everettraven , jcmoraisjr
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 (削除ここまで)[everettraven]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
|
@grzpiotrowski: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. |
grzpiotrowski
commented
Feb 23, 2026
/retest
Uh oh!
There was an error while loading. Please reload this page.
This PR fixes OCPBUGS-32275.
Adds
spec.domainfield validation in the Ingress config CRD to make it immutable and match the documentation. Prior to this commit the domain value could be changed and cause degraded state of some cluster operators.