kubernetes-sigs/cluster-api

Aggregate Deleting Condition Messages from Underlying Resources in CAPI v1beta2

Open

#11,900 opened on Feb 25, 2025

View on GitHub
 (7 comments) (0 reactions) (0 assignees)Go (1,532 forks)auto 404
area/conditionshelp wantedkind/featurepriority/backlogtriage/accepted

Repository metrics

Stars
 (4,267 stars)
PR merge metrics
 (PR metrics pending)

Description

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

Contributor guide