Delete is a verb, so it's ok to use a verb here: OrphanChildren

Do we have a clear parent child relationship defined somewhere?

Do we need something like controllerRef to materalize the same basic thing we have today for ObjectMeta.Namespace so the relationship is explicit?

I would like to find a way to use one of the existing deletion fields (e.g., DeletionTimestamp)

In the draft I wrote "we can reuse ObjectMeta.DeletionTimestamp if the DeletionTimestamp does not require the resource to be deleted after the time stamp is reached".
On second thought, this shouldn't prevent us from reusing the DeletionTimestamp, because no matter whether we reuse it, finalizers will break this on-time deletion promise made by the DeletionTimestamp.
cc @smarterclayton.

DeletionTimestamp changes when you call delete multiple times for a resource that is undergoing graceful termination... so I think you want a different field/concept.

Technically DeletionTimestamp is not a promise. Because we don't assume global time in the cluster, DeletionTimestamp is a best effort record of the anticipated deletion of the resource. No component in the cluster should be using DeletionTimestamp as a clock comparison (they should be using their own clock and incrementing it by GracefulDeletionPeriodSeconds in their own timeline).

Once DeletionTimestamp is set, it can never be unset (by API contract).

We only need to check whether DeletionTimesstamp is non-nil, its value doesn't matter.

It's value does matter for pods, right?

@smarterclayton thanks for the clarification. The comment in types.go (

@derekwaynecarr, I mean its value doesn't matter to the finalizers, because finalizers only check if DeletionTimestamp is nil. And finalizers should only update objects, which won't modify the DeletionGracePeriod or DeletionTimestamp (see https://github.com/kubernetes/kubernetes/blob/master/pkg/api/validation/validation.go#L353), so introducing finalizers won't affect the graceful termination. Did I miss something?

@caesarxuchao - it matters for who does the final delete call to the API server. In the current namespace pattern, the finalizer controller will send a delete when it observes all finalizers have emptied. in the case for pods, the kubelet will send a delete ?gracePeriod=0 which would have expected the pod to be removed. I guess I need to think a little more about what it would mean to attach a finalizer to a pod and the kubelet interaction associated.

The following is how I imagine it will work, feel free to point out the loopholes:
In API server's deletion handler, if gracePeriod=0 and the finalizers field is empty, then deletes the object immediately; otherwise just do an update, which will set the DeletionGracePeriod.
And when the last finalizer has done its job and sent an Update request to API server, API server will notice the finalizers are empty, it checks if gracePeriod=0, if so, API server deletes it; otherwise API server just updates the finalizers field to empty, some other parties will send a delete with graceperiod=0 later.

A pod may exist for a while after kubelet sends a deletion request with gracePeriod=0, and kubelet will continue to receive update event about the pod as its finalizers get removed, so kubelet will send more deletion requests with gracePeriod=0, but I think it's harmless.

If we reuse the DeletionTimestamp field, here API server also needs to check if DeletionGracePeriod is 0, if so, immediately deletes the object, otherwise just carries out the update.

"Parent" doesn't have any obvious, standard meaning. OwnerReferences may be more familiar, similar to the usual concept of object/memory ownership.

We'd need to think of another term for "Children", however.

Also, we can't change the default behavior for existing APIs/versions, so cascading deletion needs to not happen by default through the API, or, equivalently, orphaning needs to occur by default.

We'd need to think of another term for "Children", however.

How about "Dependent"? It sounds like a good match to "owner".

I'll update the terminology after we decide the winner of the two designs. The new terminology is already used in the PR that adds the API #23928.

The current Namespace finalizer is similar to the dependent object, but in this case the dependency is a cluster provider of some kind (Kubernetes, OpenShift). If we go this route for dependencies as a object reference, we need to let non-namespaced resources depend on something akin to a API provider that must be registered with the cluster. I also could see the same value in Node(s)

I guess the general question is if cluster-scoped resources can have dependents and to what things.

I'm not sure I follow, can you give an example?

On Tue, Apr 12, 2016 at 8:30 PM, Derek Carr notifications@github.com
wrote:

In docs/proposals/cascading-deletion.md
#23656 (comment)
:

+type DeleteOptions struct {

• …
• OrphanChildren bool
  +}
  +`

+DeleteOptions.OrphanChildren: allows a user to express whether the child objects should be orphaned.
+
+`
+type ObjectMeta struct {

• ...
• ParentReferences []ObjectReference
  +}
  +```

+ObjectMeta.ParentReferences: links the resource to the parent resources. For example, a replica setRcreated by a deploymentDshould have an entry in ObjectMeta.ParentReferences pointing toD. The link should be set when the child object is created. It can be updated after the creation.

The current Namespace finalizer is similar to the dependent object, but in
this case the dependency is a cluster provider of some kind (Kubernetes,
OpenShift). If we go this route for dependencies as a object reference, we
need to let non-namespaced resources depend on something akin to a API
provider that must be registered with the cluster. I also could see the
same value in Node(s)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/kubernetes/kubernetes/pull/23656/files/cc943fae771b704370a7ddca1d6267b6786fd807#r59488717

Explicitly listed "propagating the grace period" as non goal of this proposal.

Moved "propagating grace period" to Open Qeustions and noted down the tentative solution.