Recheck deletion cases when using clustercache

[chrischdi]

What steps did you take and what happened?

In CAPV we had a bug report which was due to the introduction of the new ClusterCache and regarding retry handling.

To be more specific: the case was about a deletion, where in the unhappy path we were waiting forever for the cluster connection to come back and basically blocking deletion forever.

What did you expect to happen?

• Controllers to successfully reconcile deletion and remove finalizers when applicable also when remote connection to workload cluster is down.

Cluster API version

v1.9.0

Kubernetes version

No response

Anything else you would like to add?

I checked for occurencies of where we use clustercache.ErrClusterNotConnected.

We should check the following controllers, especially on reconcile deletion and assert what is happening there

• ./controlplane/kubeadm/internal/controllers/controller.go
• ./exp/internal/controllers/machinepool_controller.go
• ./internal/controllers/machine/machine_controller.go:
• ./internal/controllers/machineset/machineset_controller.go

Label(s) to be applied

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

[chrischdi]

/assign

[k8s-ci-robot]

This issue is currently awaiting triage.

If CAPI contributors determine 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-sigs/prow repository.