v1.10 `MinLength` validation breaks managed MPs

[mboersma]

What steps did you take and what happened?

The new validations added in #11949 cause errors for CAPZ deploying managed MachinePool clusters.

The dataSecretName is not used in our managed MP case, so historically we have set it to an empty string in our templates and in documentation. This now triggers an error:

spec.template.spec.bootstrap.dataSecretName in body should be at least 1 chars long

See kubernetes-sigs/cluster-api-provider-azure#5589 for more details

What did you expect to happen?

Expected backward compatibility with previous behavior: i.e., no errors with an empty dataSecretName.

Cluster API version

v1.10.1

Kubernetes version

No response

Anything else you would like to add?

We are trying to work around this by setting dataSecretName to "unused," but even if that works, it's fragile and hacky. Could we consider reverting this validation? I know we had to relax another validation in #12107.

Label(s) to be applied

/kind bug

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[sbueringer]

Duplicate with: #12160?

[tamalsaha]

Closed my duplicate issue.

[mboersma]

Oops sorry @tamalsaha we were thinking the same thing. :-)

[sbueringer]

Sorry, my mistake. I should have remembered this use case when adding the validation. I would say let's change the validation to // +kubebuilder:validation:MinLength=0. It's equivalent to not having minLength but it shows at least that we thought about MinLength and makes it explicit that strings with 0 length are valid

[mboersma]

/assign