/kind bug
What steps did you take and what happened:
When deleting a managed GKE cluster, the GCPManagedMachinePool object frequently gets stuck in termination with its finalizer never removed, even after the GCP resources are confirmed gone. The only workaround is to manually kubectl edit the object and delete the finalizer.
What did you expect to happen:
The finalizer would be removed when the GCP NodePool disappears and the cascading deletion of the other dependent resources would continue with no manual intervention
Anything else you would like to add:
When a GKE cluster is deleted, GCP automatically deletes all associated node pools. CAPG independently tries to call DeleteNodePool for each pool. If GCP has already cleaned up the node pool by the time CAPG issues its request, the API returns NotFound.
deleteNodePool() in cloud/services/container/nodepools/reconcile.go does not handle NotFound — it propagates the error, which sets GKEMachinePoolDeletingCondition to ReconciliationFailed. The finalizer removal gate in the controller checks specifically for DeletedReason, so the finalizer is never removed and the object is stuck until manually unblocked.
describeNodePool() in the same file already handles NotFound correctly (treating it as a nil return). deleteNodePool() should follow the same pattern.
Further it seems that the E2E tests, don't explicitly assert on deletion semantics so this is a small coverage gap in the E2Es
Environment:
- Cluster-api version: 0.26.0 (Cluster API Operator)
- Minikube/KIND version: N/A
- Kubernetes version: (use
kubectl version): 1.35.1
- OS (e.g. from
/etc/os-release): CoreOS
/kind bug
What steps did you take and what happened:
When deleting a managed GKE cluster, the
GCPManagedMachinePoolobject frequently gets stuck in termination with its finalizer never removed, even after the GCP resources are confirmed gone. The only workaround is to manually kubectl edit the object and delete the finalizer.What did you expect to happen:
The finalizer would be removed when the GCP NodePool disappears and the cascading deletion of the other dependent resources would continue with no manual intervention
Anything else you would like to add:
When a GKE cluster is deleted, GCP automatically deletes all associated node pools. CAPG independently tries to call DeleteNodePool for each pool. If GCP has already cleaned up the node pool by the time CAPG issues its request, the API returns NotFound.
deleteNodePool()in cloud/services/container/nodepools/reconcile.go does not handle NotFound — it propagates the error, which sets GKEMachinePoolDeletingCondition toReconciliationFailed. The finalizer removal gate in the controller checks specifically for DeletedReason, so the finalizer is never removed and the object is stuck until manually unblocked.describeNodePool() in the same file already handles NotFound correctly (treating it as a nil return). deleteNodePool() should follow the same pattern.
Further it seems that the E2E tests, don't explicitly assert on deletion semantics so this is a small coverage gap in the E2Es
Environment:
kubectl version): 1.35.1/etc/os-release): CoreOS