From 4820730ba1838827f2678c7b9c3139a72b340280 Mon Sep 17 00:00:00 2001 From: Jordan Liggitt Date: Tue, 24 Sep 2024 22:11:35 -0400 Subject: [PATCH 1/2] Clarify foreground deletion behavior of the GC controller in race and sync error conditions --- .../docs/concepts/architecture/garbage-collection.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/content/en/docs/concepts/architecture/garbage-collection.md b/content/en/docs/concepts/architecture/garbage-collection.md index e0a2b0af7177f..a87f3c7a27157 100644 --- a/content/en/docs/concepts/architecture/garbage-collection.md +++ b/content/en/docs/concepts/architecture/garbage-collection.md @@ -82,13 +82,16 @@ owner object: * The object remains visible through the Kubernetes API until the deletion process is complete. -After the owner object enters the deletion in progress state, the controller -deletes the dependents. After deleting all the dependent objects, the controller -deletes the owner object. At this point, the object is no longer visible in the +After the owner object enters the *deletion in progress* state, the controller +deletes dependents it knows about. After deleting all the dependent objects it knows about, +the controller deletes the owner object. At this point, the object is no longer visible in the Kubernetes API. During foreground cascading deletion, the only dependents that block owner -deletion are those that have the `ownerReference.blockOwnerDeletion=true` field. +deletion are those that have the `ownerReference.blockOwnerDeletion=true` field +and are in the garbage collection controller cache. The garbage collection controller +cache may not contain objects whose resource type cannot be listed / watched successfully, +or objects which are created concurrent with deletion of an owner object. See [Use foreground cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion) to learn more. From 444abaa00335d960a48b13cd0e667f76bc6ac680 Mon Sep 17 00:00:00 2001 From: Jordan Liggitt Date: Wed, 25 Sep 2024 00:21:25 -0400 Subject: [PATCH 2/2] Update content/en/docs/concepts/architecture/garbage-collection.md Co-authored-by: Tim Bannister --- content/en/docs/concepts/architecture/garbage-collection.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/architecture/garbage-collection.md b/content/en/docs/concepts/architecture/garbage-collection.md index a87f3c7a27157..8b91d3ef8672f 100644 --- a/content/en/docs/concepts/architecture/garbage-collection.md +++ b/content/en/docs/concepts/architecture/garbage-collection.md @@ -91,7 +91,7 @@ During foreground cascading deletion, the only dependents that block owner deletion are those that have the `ownerReference.blockOwnerDeletion=true` field and are in the garbage collection controller cache. The garbage collection controller cache may not contain objects whose resource type cannot be listed / watched successfully, -or objects which are created concurrent with deletion of an owner object. +or objects that are created concurrent with deletion of an owner object. See [Use foreground cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion) to learn more.