kubernetes-sigs/cluster-api

Aggregate Deleting Condition Messages from Underlying Resources in CAPI v1beta2

開放

#11,900 建立於 2025年2月25日

 (8 則留言) (0 個反應) (1 位負責人)Go (1,532 個分叉)auto 404
area/conditionshelp wantedkind/featurepriority/backlogtriage/accepted

倉庫指標

星標
 (4,267 顆星)
PR 合併指標
 (PR 指標待抓取)

描述

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

貢獻者指南