github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-07-27 13:37:30 +00:00
Code Issues Projects Releases Wiki Activity

remove ConfigMap example from GC proposal

Browse Source
This commit is contained in:
Chao Xu 2016-05-20 14:17:24 -07:00
parent 1cce156597
commit d803a0e37f
1 changed files with 1 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/proposals/garbage-collection.md
View File

@ -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) - [Upgrading a cluster to support cascading deletion](#upgrading-a-cluster-to-support-cascading-deletion)
- [End-to-End Examples](#end-to-end-examples) - [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 Deployment and its descendants](#life-of-a-deployment-and-its-descendants)
- [Life of a ConfigMap](#life-of-a-configmap)
- [Open Questions](#open-questions) - [Open Questions](#open-questions)
- [Considered and Rejected Designs](#considered-and-rejected-designs) - [Considered and Rejected Designs](#considered-and-rejected-designs)
- [1. Tombstone + GC](#1-tombstone--gc) - [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 # 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 ## 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*. 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. 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 # 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? 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?