kubernetes-sigs/cluster-api

Aggregate Deleting Condition Messages from Underlying Resources in CAPI v1beta2

Aberta

#11.900 aberto em 25 de fev. de 2025

 (8 comentários) (0 reação) (1 responsável)Go (1.532 forks)auto 404
area/conditionshelp wantedkind/featurepriority/backlogtriage/accepted

Métricas do repositório

Stars
 (4.267 estrelas)
Métricas de merge de PR
 (Métricas PR pendentes)

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

Guia do colaborador