Merge pull request #25990 from caesarxuchao/remove-configmap-ex

Automatic merge from submit-queue

remove ConfigMap example from GC proposal

We need more thoughts on the design. Remove it to avoid causing confusion.

@derekwaynecarr  @lavalamp 

1 files changed, 1 insertions, 12 deletions

diff --git a/garbage-collection.md b/garbage-collection.md
index 06e49a1f..8b6afde6 100644
--- a/garbage-collection.md
+++ b/garbage-collection.md
@@ -39,7 +39,6 @@ Documentation for other releases can be found at
   - [Upgrading a cluster to support cascading deletion](#upgrading-a-cluster-to-support-cascading-deletion)
 - [End-to-End Examples](#end-to-end-examples)
   - [Life of a Deployment and its descendants](#life-of-a-deployment-and-its-descendants)
-  - [Life of a ConfigMap](#life-of-a-configmap)
 - [Open Questions](#open-questions)
 - [Considered and Rejected Designs](#considered-and-rejected-designs)
 - [1. Tombstone + GC](#1-tombstone--gc)
@@ -207,7 +206,7 @@ For kubectl, we will keep the kubectl’s cascading deletion logic for one more
 
 # End-to-End Examples
 
-This section presents two examples of all components working together to enforce the cascading deletion or orphaning.
+This section presents an example of all components working together to enforce the cascading deletion or orphaning.
 
 ## Life of a Deployment and its descendants
 
@@ -239,16 +238,6 @@ This section presents two examples of all components working together to enforce
 12. The Propagator of the GC observes the deletion of `D1`. It deletes `D1` from the DAG. It adds its dependent, replicaset `R1`, to the *Dirty Queue*.
 13. The Garbage Processor of the GC dequeues `R1` from the *Dirty Queue* and skips it, because its OwnerReferences is empty.
 
-## Life of a ConfigMap
-
-1. User creates a ConfigMap `C1`.
-2. User creates a Deployment `D1`, which refers `C1` in the pod template.
-3. The deployment controller has observed the creation of `D1`. It creates replicaset `R1`, which also refer `C1` in the pod template. It then updates `C1`, adding `R1` to the OwnerReferences.
-4. `R1` is deleted with DeleteOptions.OrphanDependents=false, either caused by the cascading deletion of `D1`, or a rolling update of `D1` where `R1` is removed from the deployment revision history.
-5. API server handles the deletion of `R1`, it first removes the "orphan" finalizer from `R1`'s Finalizers map is it's present, then it deletes `R1` from the registry.
-6. The Propagator of the GC observes the deletion of `R1`. It deletes `R1` from the DAG. It adds its dependent objects, including ConfigMap `C1`, to the *dirty queue*.
-7. The Garbage Processor of the GC dequeues `C1` from the *dirty queue*. `C1` may have owner references to other replicasets. If none of its owners exist, the Garbage Processor requests API server to delete `C1`. Otherwise, it does nothing.
-
 # Open Questions
 
 1. In case an object has multiple owners, some owners are deleted with DeleteOptions.OrphanDependents=true, and some are deleted with DeleteOptions.OrphanDependents=false, what should happen to the object?