Aggregate Deleting Condition Messages from Underlying Resources in CAPI v1beta2

[LingyanCao]

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

As a developer, I would like to get the deleting status of all CAPI underlying resources from CAPI cluster CR.

Detailed Description

In CAPI v1beta2, the Deleting condition was introduced to track resource deletion progress. However, unlike the provisioning flow, the Deleting condition only checks whether a resource’s directly owned resources are deleted. It does not aggregate the Deleting condition reasons or error messages from underlying resources.

For example, when a Cluster resource is being deleted, it checks if the KubeadmControlPlane (KCP) CR is deleted. If not, it sets the Deleting condition with:

Reason: WaitingForControlPlaneDeletion
Message: Waiting for KubeadmControlPlane to be deleted
However, it does not read the Deleting condition from KubeadmControlPlane or propagate any underlying error messages that might explain why the deletion is blocked. This makes it difficult to diagnose failures, especially when dealing with infrastructure-related issues.

Would the community consider enhancing the Deleting condition aggregation to include underlying error messages from child resources, similar to how condition aggregation works in the provisioning flow?

Anything else you would like to add?

No response

Label(s) to be applied

/kind feature
/area conditions

[fabriziopandini]

Would the community consider enhancing the Deleting condition aggregation to include underlying error messages from child resources, similar to how condition aggregation works in the provisioning flow?

Do you have an example on how this should look like?

Some background info that can help in the discussion down the line:

• Deleting conditions for KCP, MD, MS shows a very synthetic message, x machines are deleting, eventually adding the number of machines in stale deletion; details of issues in deleting machines can be found in MachinesReady condition.
• Deleting condition for cluster is slightly different:
  • While the descendant objects are being deleted, it provides a partial list of objects being deleted (one for MD, MS, MP, Machines); details of issues in deleting machines can be found in MachinesReady condition.
  • After descendant objects are deleted, it surfaces "Waiting for YourControlPlane to be deleted" and "Waiting for YourClusterInfrastructure to be deleted"; details of issues in deleting control plane machines can be found in MachinesReady condition.
• We should keep in mind that according to the contract ControlPlane objects are not required to report conditions, nor they are required to have a notion of replicas or to represented those replicas with a set of Cluster API Machines.

[fabriziopandini]

Slightly related, we might want to consider also to surface Paused objects preventing deletion

[sbueringer]

/reopen

I would still like to track this use case

[k8s-ci-robot]

@sbueringer: Reopened this issue.

In response to this:

/reopen

I would still like to track this use case

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.

[sbueringer]

/triage accepted

General idea of improving the condition makes sense, we need help figuring out the details