✨ Additional validation in Cluster/ClusterClass webhook for chained upgrades

[Karthik-K-N]

What this PR does / why we need it:
This PR will contain series of commits to add additional validation for Cluster/ClusterClass webhook for chained upgrades and associated UTs.

More info: #12720 (comment)

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Part of #12720

/area clusterclass

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign enxebre for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[Karthik-K-N]

Apologies for delay, back from small vacation, will add other pending changes for clusterclass webhook and UT in following commits.

[sbueringer]

No problem! Welcome back and thx for working on this!

[Karthik-K-N]

Added UT for cluster webhook
Added validation for ClusterClass update scenario.
Only thing pending is ClusterClass create case, will take that up if this approach looks good,

PR is ready for initial review.

[Karthik-K-N]

Asking my question regarding this point here

ClusterClass webhook: on create/update: ensure versions of all Clusters using that ClusterClass are included in ClusterClass versions (if CC has versions)

I am bit confused about this check (if CC has versions)*

For example we have a CC A with versions 1.32, 1.33, Then we create new CC B for rebase with no version. Since there are no KubernetesVersion set on CC B, this check makes it as valid.
But in this case what will the Cluster use, will it continue to remain in its version?

[sbueringer]

Good question.

The idea is to only check Cluster.spec.topology.version if a ClusterClass has kubernetesVersions defined.
As defining kubernetesVersions on the CC is entirely optional it is valid to use a CC without versions or rebase to one without versions.

We only want to make sure that if the CC has versions the Cluster uses one of them. Basically either you opt-into defining the versions in the CC and you get the corresponding features, or you don't and you get the same behavior as today

For example we have a CC A with versions 1.32, 1.33, Then we create new CC B for rebase with no version. Since there are no KubernetesVersion set on CC B, this check makes it as valid.

That's correct

But in this case what will the Cluster use, will it continue to remain in its version?

Yes. The Cluster will just continue to use the version it has.

[Karthik-K-N]

Got it, Thanks for clarifying.