Add validation for KubeadmConfigSpec defaulting

[sbueringer]

We repeatedly had the issue that we added new defaulting to KubeadmConfigSpec fields, which lead to rollouts in KCP after CAPI upgrade:

• 6093

• 8124

The goal of this issue is to add some sort of validation that we can run as part of presubmits to ensure this doesn't happen again.

We basically want to validate that all defaulting that we implement for KubeadmConfigSpec is done in DefaultKubeadmConfigSpec and not via OpenAPI.

Some ideas:

• Add a defaulting unit test:
  • It would compare results of local KubeadmConfig defaulting with KubeadmConfig.Default() vs. KubeadmConfig create with envtest
  • => If there is a difference => there was additional defaulting via OpenAPI
• Introduce a new linter. Options:
  • check for default field in final CRD YAMLs
  • check for // +kubebuilder:default marker in KubeadmConfigSpec struct and below (controller-tools based linter)

/kind feature /area control-plane

[sbueringer]

@vincepri @fabriziopandini @ykakarap

The unit tests sounds sufficient and pretty straightforward to me, WDYT?

[ykakarap]

Yup, unit test looks like a good idea. +1. Since we will use envtest with the defaulting webhook it will closely reflect the real world case too.

[fabriziopandini]

/triage accepted /help 💯 this will be very useful!

[k8s-ci-robot]

@fabriziopandini: This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed by commenting with the /remove-help command.

In response to [this](https://github.com/kubernetes-sigs/cluster-api/issues/8147): >/triage accepted >/help >💯 this will be very useful! > Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[sbueringer]

Let's see if some takes this over. I added it to the v1.5 milestone to ensure we'll implement it until then.

I would take over if nobody volunteers until then.

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[sbueringer]

/triage accepted