✨ Add types and hook for GenerateUpgradePlan

[sivchari]

What this PR does / why we need it:

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

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

[sbueringer]

Suggested change

	// cluster is the cluster ofject the lifecycle hook correspods to.
	// +required
	Cluster clusterv1beta1.Cluster `json:"cluster,omitempty,omitzero"`
	// cluster is the cluster object the GenerateUpgradePlan request corresponds to.
	// +required
	Cluster clusterv1.Cluster `json:"cluster,omitempty,omitzero"`

Let's go with v1beta2. I know the proposal says v1beta1, but we already decided for the in-place implementation to just directly go with v1beta2 to avoid conversion issues. I would do the same here

[fabriziopandini]

+1 on using v1beta2 (sorry I forgot to update the comment with implementation details for this PR 😅)

[sbueringer]

Not sure about all the kubebuilder:validation: + listType markers. None of these are used anywhere as these are not CRDs so nobody implements the corresponding validation.
I would probably remove them (but let's definitely keep optional + required, this seems like useful info in general)

@fabriziopandini WDYT?

[fabriziopandini]

For the request I think it is ok to have both +required and MinLength, because CAPI will always send a value for the fields that are currently marked as required (and the field that is marked optional will have lenght > 1 when set)

For the response I think it makes sense to keep markers only what we are going enforcing when we are validating the response in

cluster-api/exp/topology/desiredstate/upgrade_plan.go

Line 133 in 9db4c78

func DefaultAndValidateUpgradePlans(desiredVersion string, controlPlaneVersion string, minWorkersVersion string, controlPlaneUpgradePlan []string, workersUpgradePlan []string) ([]string, error) {

.
Accordingly, let's drop both listType and Min/MaxItems for both arrays.

[fabriziopandini]

Thanks for this PR!

[fabriziopandini]

Let's add some more details on the rules that applies to the upgrade plan

Suggested change

	// controlPlaneUpgrades is the list of version upgrade steps for the control plane.
	// Each entry represents an intermediate version that must be applied in sequence.
	// controlPlaneUpgrades is the list of version upgrade steps for the control plane.
	// Each entry represents an intermediate version that must be applied in sequence.
	// The following rules apply:
	// - there should be at least one version for every minor between fromControlPlaneKubernetesVersion (excluded) and ToKubernetesVersion (included).
	// - each version must be:
	// - greater than fromControlPlaneKubernetesVersion (or with a different build number)
	// - greater than the previous version in the list (or with a different build number)
	// - less or equal to ToKubernetesVersion (or with a different build number)
	// - the last version in the plan must be equal to ToKubernetesVersion

[fabriziopandini]

Suggested change

	// workersUpgrades is the list of version upgrade steps for the workers.
	// Each entry represents an intermediate version that must be applied in sequence.
	// workersUpgrades is the list of version upgrade steps for the workers.
	// Each entry represents an intermediate version that must be applied in sequence.
	//
	// In case the upgrade plan for workers will be left to empty, the system will automatically
	// determine the minimal number of workers upgrade steps, thus minimizing impact on workloads and reducing
	// the overall upgrade time.
	//
	// If instead for any reason a custom upgrade path for workers is required, the following rules apply:
	// - each version must be:
	// - equal to FromControlPlaneKubernetesVersion or to one of the versions in the control plane upgrade plan.
	// - greater than FromWorkersKubernetesVersion (or with a different build number)
	// - greater than the previous version in the list (or with a different build number)
	// - less or equal to the ToKubernetesVersion (or with a different build number)
	// - in case of versions with the same major/minor/patch version but different build number, also the order
	// of those versions must be the same for control plane and worker upgrade plan.
	// - the last version in the plan must be equal to ToKubernetesVersion
	// - the upgrade plane must have all the intermediate version which workers must go through to avoid breaking rules
	// defining the max version skew between control plane and workers.

[fabriziopandini]

Suggested change

	// fromWorkersKubernetesVersion is the current Kubernetes version of the workers.
	// fromWorkersKubernetesVersion is the min Kubernetes version of the workers (MachineDeployments and MachinePools).

[fabriziopandini]

Suggested change

	"- The response may include separate upgrade paths for control plane and workers\n" +
	"- The response may include separate upgrade paths for control plane and workers\n" +
	"- The upgrade plan for workers is optional; if missing the system will automatically\n\"" +
	" determine the minimal number of workers upgrade steps according to Kubernetes version skew rules.\n" +