Tracking issue for v1Beta2 - MachinePools

[richardcase]

This is to track the v1beta2 changes for machine pools and is an extension of the other v1beta2 work being tracked on #11947

From proposal

• [ ] Disambiguate the usage of the ready term by renaming fields used for the initial provisioning workflow - https://github.com/kubernetes-sigs/cluster-api/pull/12102 - Matt to confirm
• [ ] Update ReadyReplicas counter to use the same semantic Machine's Ready condition and add missing UpToDateReplicas - https://github.com/kubernetes-sigs/cluster-api/pull/12066 - Matt to confirm
• [ ] Align MachinePools replica counters to other CAPI resources - Rich
  • https://github.com/kubernetes-sigs/cluster-api/issues/12413
• [ ] Remove FailureReason and FailureMessage to get rid of the confusing concept of terminal failures - Matt to confirm
• [ ] Transition to new, improved, K8s API conventions aligned conditions

From parent issue

• [ ] MachinePool conditions
  • [ ] Implement conditions on MachinePools and MachinePool Machines (UpToDate)
  • [ ] Revert https://github.com/kubernetes-sigs/cluster-api/pull/11416
• [ ] DockerMachinePool
  • [ ] Add v1beta2 struct
  • [ ] Paused

Other things

• [ ] Find a better solution for bootstrap.dataSecretName="" for machine pools (especially "managed" varieties) see #12164
• [ ] Add MachinePool contract documentation as per @fabriziopandini comment(https://github.com/kubernetes-sigs/cluster-api/issues/12178#issuecomment-2867348408)

/area machinepool /area api

[richardcase]

/priority important-soon /assign /assign mboersma

[fabriziopandini]

If you all agree I would add to the tracking issue the work for implementing a page for MP contract documentation under https://cluster-api.sigs.k8s.io/developer/providers/contracts/overview

note: we have something under https://cluster-api.sigs.k8s.io/developer/core/controllers/machine-pool but this is the wrong place, and also we should align the documentation to what has been done e.g. for https://cluster-api.sigs.k8s.io/developer/providers/contracts/infra-machine (or other contracts)

The main advantage is that this could help to start consolidating the knowledge about various MP incantations that exists and their implications in core Cluster API thus avoiding discussion/issues like e.g. https://github.com/kubernetes-sigs/cluster-api/pull/12164#issuecomment-2863080203

[chrischdi]

/triage accepted

[fabriziopandini]

@richardcase it will be great if we can also add a work item to implement a cleanup similar to https://github.com/kubernetes-sigs/cluster-api/pull/12352.

TL;DR In status.nodeRefs, use a trimmed down custom type instead of corev1.ObjectReference (this can also help mitigate https://github.com/kubernetes-sigs/cluster-api/issues/6387)

[richardcase]

Align MachinePools replica counters to other CAPI resources

I believe this item is already done @mboersma & @fabriziopandini

[fabriziopandini]

Align MachinePools replica counters to other CAPI resources

I believe this item is already done @mboersma & @fabriziopandini

I just checked the code, it is not. I have renamed the fields to try to get out of the table all the breaking changes, but the semantic of those field is not correct. (e.g. ReadyReplicas is still the number of machines with a ready node, while it should be the number of machines with Ready condition true, and so on)

[richardcase]

Ah got it, thanks @fabriziopandini

[richardcase]

@mboersma - just to let you know i'm working on Align MachinePools replica counters to other CAPI resources, should have a PR up in the next few days. After my misunderstanding i see where i need to make the change (thanks @fabriziopandini ).

[richardcase]

Lets not forgot this as well: https://github.com/kubernetes-sigs/cluster-api/issues/10059

[k8s-triage-robot]

This issue is labeled with priority/important-soon but has not been updated in over 90 days, and should be re-triaged. Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Deprioritize it with /priority important-longterm or /priority backlog
• Close this issue with /close

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

/remove-triage accepted

[richardcase]

/priority important-longterm