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

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

Browse Source 
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
This commit is contained in:
k8s-merge-robot 2016-05-23 21:02:33 -07:00
commit 2dbda8c705
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)
- [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?