kubernetes-sigs/cluster-api

How to surfacing runtime hook blocking cluster deletion in condition

Offen

#6.807 geöffnet am 02.07.2022

Auf GitHub ansehenContributor Guide
 (10 Kommentare) (0 Reaktionen) (0 zugewiesene Personen)Go (1.532 Forks)auto 404
area/runtime-sdkhelp wantedkind/cleanuppriority/important-longtermtriage/accepted

Repository-Metriken

Stars
 (4.267 Sterne)
PR-Merge-Metriken
 (PR-Metriken ausstehend)

Beschreibung

Details:

This issue is to discuss how to surface that a cluster deletion is blocked when the BeforeClusterDelete hook blocks the deletion of a process with a blocking response.

We have 2 options:

  1. Use TopologyReconciled condition - Since only managed clusters are affected by BeforeClusterDelete hook we can use the TopologyReconciled condition to surface if a cluster deletion is blocked. Reason will be LifecycleHookBlocking. This will be consistent with how the other lifecycle hook blocking cases are surfaced.

  2. Use a separate condition - Since TopologyReconciled condition reflects if the underlying objects reflect the topology spec of the cluster using it for delete might be deviating from it purpose.

Some additional concerns:

  • How should the condition be updated after deletion is unblocked and the cluster is in the process of deleting the objects?
  • Which controller owns this condition?

/area runtime-sdk

Contributor Guide

Research-Richtung
Untersuche die vorhandene TopologyReconciled Bedingung und den BeforeClusterDelete Hook, um zu entscheiden, wie die Blockierung der Clusterlöschung am besten dargestellt werden kann. Betrachte die beiden Optionen: Verwendung der TopologyReconciled Bedingung mit dem Grund LifecycleHookBlocking oder einer separaten Bedingung. Gehe auch auf die Bedenken ein, wie die Bedingung nach dem Aufheben der Blockierung aktualisiert wird und welcher Controller sie besitzt.
Tech Stack
go
Domain
apibackenddevops
Issue Type
Funktion
SchwierigkeitGeschätzte Implementierungsschwierigkeit für neue Contributors, von 1 für sehr kleine Änderungen bis 5 für Expertenarbeit.
3
Geschätzte ZeitEin grober Zeitrahmen, um zu recherchieren, zu implementieren, zu testen und einen Pull Request vorzubereiten.
1-2 Tage
AktivitätsstatusWie verfügbar das Issue gerade wirkt: frisch, aktiv, stale, blockiert oder wartet auf Maintainer-Input.
Aktiv
KlarheitWie klar das Issue die erwartete Änderung, Akzeptanzkriterien und den nächsten Schritt erklärt.
Klar
Voraussetzungen
KubernetesCluster API
EinsteigerfreundlichkeitEin Score von 1 bis 100, der schätzt, wie zugänglich dieses Issue für First-Time Contributors ist.
30