Using `IntOrString` with `Pattern` causes validation to not occur when Int is specified

[jonathan-innis]

We're using controller-gen generation in the aws/karpenter-provider-aws project, but we see that a pattern that we are using in our CRD is not validated when the key is of type IntOrString and the value that is passed-through is an integer. It doesn't seem to actually get validated until we attempt to update the resource later after the resource has already been applied to the apiserver. This causes resources to get stuck because they don't adhere to the "pattern" that is specified in the validation section, but the initial create is not rejected.

For example, I created a small repo that exemplifies this. When i install the test resource, and then apply the examples, I see the expected behavior when the inputs are strings; however, once the input becomes an integer, it passes right by the pattern validation.

# Install the CRDs from the repository
make install

# Apply a valid Test resource
kubectl apply -f config/samples/test_v1_valid_str.yaml

# Apply an invalid Test resource, see it fails
kubectl apply -f config/samples/test_v1_invalid_str.yaml

# Apply an invalid Test resource that doesn't adhere to the pattern but specifies an integer, see it passes when it shouldn't
kubectl apply -f config/samples/test_v1_valid_int.yaml

[sbueringer]

According to the openapi spec pattern only applies to strings: https://swagger.io/docs/specification/data-models/data-types/#pattern

I assume the apiserver implemented it according to the spec.

I would recommend to use cel with the quantity function to implement this validation: https://kubernetes.io/docs/reference/using-api/cel/#kubernetes-quantity-library

In general this issue seems unrelated to controller-gen

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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.