github/kubernetes
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

addressing comments

Browse Source
This commit is contained in:
Chao Xu 2016-09-13 21:12:17 -07:00
parent 5d9e3615f0
commit d67eb53db2
1 changed files with 21 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
docs/proposals/synchronous-garbage-collection.md
View File

@ -35,7 +35,9 @@ Delete() function needs to check the DeleteOptions.SynchronousGarbageCollection.
**Modifications to processEvent()**
* Needs to handle Add or Update events where `obj.Finalizers.Has(GCFinalizer) && obj.DeletionTimestamp != nil`. The object will be added into the `synchronousGC queue`. The object will be marked as “GC in progress” in GC’s internal owner-dependency relationship graph, `uidToNode`.
`processEvent()` manages GC’s internal owner-dependency relationship graph, `uidToNode`. It updates `uidToNode` according to the Add/Update/Delete events in the cluster. To support synchronous GC, it has to:
* handle Add or Update events where `obj.Finalizers.Has(GCFinalizer) && obj.DeletionTimestamp != nil`. The object will be added into the `synchronousGC queue`. The object will be marked as “GC in progress” in `uidToNode`.
* Upon receiving the deletion event of an object, put its owner into the `synchronousGC queue`. This is to force the `GCFinalizer` (described next) to re-check if all dependents of the owner is deleted.
**Addition of GCFinalizer() routine**
@ -45,15 +47,27 @@ Delete() function needs to check the DeleteOptions.SynchronousGarbageCollection.
* To avoid racing with another controller, it requeues the object if `observedGeneration < Generation`. This is best-effort, see [unhandled cases](#unhandled-cases).
* Checks if the object has dependents
* If not, send a PUT request to remove the GCFinalizer
* If so, then add all dependents to the dirtryQueue; we need bookkeeping to avoid adding the dependents repeatedly if the owner gets in the `synchronousGC queue` multiple times.
* If so, then add all dependents to the `dirtryQueue`; we need bookkeeping to avoid adding the dependents repeatedly if the owner gets in the `synchronousGC queue` multiple times.
**Modifications to processItem()**
* Treat owner whose DeletionTimestamp is non-nil as “not exist”.
* When deleting dependents, it should use the same `DeleteOptions.SynchronousGC` as the owner’s finalizers suggest.
`processItem()` consumes the `dirtyQueue`, requests the API server to delete an item if all of its owners do not exist. To support synchronous GC, it has to:
**Note**
We cannot have circular dependencies anymore. Otherwise SynchronousGC will enter a deadlock.
* treat an owner as "not exist" if `owner.DeletionTimestamp != nil && !owner.Finalizers.Has(OrphanFinalizer)`, otherwise Synchronous GC will not progress because the owner keeps existing in the key-value store.
* when deleting dependents, it should use the same `DeleteOptions.SynchronousGC` as the owner’s finalizers suggest.
**Handling circular dependencies**
SynchronousGC will enter a deadlock in the presence of circular dependencies. To break the deadlock, we need to timeout a GCFinalizer. To implement the timeout, GC adds an object that has a GCFinalizer into a [delaying queue](../../pkg/util/workqueue/delaying_queue.go) when it's observed, and removes the GCFinalizer from it when the time is up. The timeout value should be proportional to the number of dependents, including indirect ones.
## Unhandled cases
* If the GC observes the owning object with the GCFinalizer before it observes the creation of all the dependents, GC will remove the finalizer from the owning object before all dependents are gone. Hence, “Synchronous GC” is best-effort, though we guarantee that the dependents will be deleted eventually.
* If the GC observes the owning object with the GCFinalizer before it observes the creation of all the dependents, GC will remove the finalizer from the owning object before all dependents are gone. Hence, “Synchronous GC” is best-effort, though we guarantee that the dependents will be deleted eventually. We face a similar case when handling OrphanFinalizer, see [GC known issues](https://github.com/kubernetes/kubernetes/issues/26120).
## Implications to existing clients
**Namespce controller** can [handle finalizers](https://github.com/kubernetes/kubernetes/pull/32524), so it can properly delete a namespace if there is synchronous GC going on in the namespace. Also, we can convert namespace controller to use synchronous GC.
We should be able to convert **kubectl delete** reapers to use synchronous GC.
For other clients, they are able to work with synchronous GC as long as they can cope with finalizers in general.