Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify API validation error for toleration if operator is Exists and value is not empty #128119

Merged
merged 1 commit into from
Oct 21, 2024

Conversation

saschagrunert
Copy link
Member

@saschagrunert saschagrunert commented Oct 16, 2024

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

Without this patch the error message for this example:

---
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
    - name: agent
      image: debian:latest
  tolerations:
    - key: pool
      operator: Exists
      value: build
      effect: NoSchedule

Looks like:

The Pod "test" is invalid: spec.tolerations[0].operator: Invalid value:
core.Toleration{Key:"pool", Operator:"Exists", Value:"build",
Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}: value must be
empty when `operator` is 'Exists'

To clarify that the Value field is wrong, we now directly point the field.Invalid to it. Now the error message becomes a more clear and concise one:

The Pod "test" is invalid: spec.tolerations[0].operator: Invalid value:
"build": value must be empty when `operator` is 'Exists'

Which issue(s) this PR fixes:

None

Special notes for your reviewer:

None

Does this PR introduce a user-facing change?

Clarified an API validation error for toleration if `operator` is `Exists` and `value` is not empty.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

None

Without this patch the error message for this example:

```
---
apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
    - name: agent
      image: debian:latest
  tolerations:
    - key: pool
      operator: Exists
      value: build
      effect: NoSchedule
```

Looks like:

```
The Pod "test" is invalid: spec.tolerations[0].operator: Invalid value:
core.Toleration{Key:"pool", Operator:"Exists", Value:"build",
Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}: value must be
empty when `operator` is 'Exists'
```

To clarify that the `Value` field is wrong, we now directly point the
`field.Invalid` to it. Now the error message becomes a more clear and
concise one:

```
The Pod "test" is invalid: spec.tolerations[0].operator: Invalid value:
"build": value must be empty when `operator` is 'Exists'
```

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. sig/apps Categorizes an issue or PR as relevant to SIG Apps. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Oct 16, 2024
@sftim
Copy link
Contributor

sftim commented Oct 17, 2024

Slight changelog tweak (suggestion)

-Clarify API validation error for toleration if `operator` is `Exists` and `value` is not empty.
+Clarified an API validation error for toleration if `operator` is `Exists` and `value` is not empty.

@saschagrunert
Copy link
Member Author

Slight changelog tweak (suggestion)

-Clarify API validation error for toleration if `operator` is `Exists` and `value` is not empty.
+Clarified an API validation error for toleration if `operator` is `Exists` and `value` is not empty.

Thanks! Updated as suggested 👍

@saschagrunert
Copy link
Member Author

@kubernetes/api-approvers PTAL

/sig api-machinery
/kind cleanup

@k8s-ci-robot k8s-ci-robot added the sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. label Oct 21, 2024
@liggitt
Copy link
Member

liggitt commented Oct 21, 2024

/approve
/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 21, 2024
@k8s-ci-robot
Copy link
Contributor

LGTM label has been added.

Git tree hash: 420a156883102fc5f23dd4bdf0eb8b5a8ba44433

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: liggitt, saschagrunert

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 21, 2024
@k8s-ci-robot k8s-ci-robot merged commit 5f3316f into kubernetes:master Oct 21, 2024
14 checks passed
@k8s-ci-robot k8s-ci-robot added this to the v1.32 milestone Oct 21, 2024
@saschagrunert saschagrunert deleted the api-validation-err branch October 22, 2024 05:44
@fedebongio
Copy link
Contributor

/triage accepted

@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. lgtm "Looks good to me", indicates that a PR is ready to be merged. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/apps Categorizes an issue or PR as relevant to SIG Apps. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

5 participants