Improve validation in Cluster.spec.topology

[sbueringer]

What would you like to be added (User Story)?

I think it would be good if we can go over Cluster.spec.topology and check if we have validation for all fields where it is appropriate.

Some examples:

• MachineHealthCheckTopology: we should have validation that if enable is set to false no MachineHealthCheckClass fields should be set
• MachineDeploymentStrategy: fields from MachineRollingUpdateDeployment should only be allowed to be set if Type is RollingUpdate
  • The same check is missing in the MD webhook

We should in general check if there is any validation that we either have only in Cluster.spec.topology or the corresponding webhook of the core type (MD/MHC) and make sure they are sync.

This way we can avoid that the Cluster topology controller is creating MD/MHC objects which are already invalid based on their webhook

Detailed Description

Anything else you would like to add?

No response

Label(s) to be applied

/kind feature
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determines 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/test-infra repository.

[fabriziopandini]

Note: while enforcing those checks, we should pay attention to not blocking users with misconfigurations (e.g onDelete strategy + rollout strategy set)

[sbueringer]

This would come down to only doing this validation when the fields are newly set and keep allowing invalid values if they are already invalid?

[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

[chaunceyjiang]

/remove-lifecycle stale

[fabriziopandini]

/priority important-longterm

[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