[Feature] Ability to set grace period / force delete children.

[ikreymer]

In certain circumstances, the controller may want to delete children more quickly / force delete instead of using the default grace period. Perhaps there's a way to support the equivalent of the kubectl --grace-period option as part of the Sync response hook?
If gracePeriod is set as part of the Sync response, and any children need to being deleted from that response, the controller would use the specified grace period. (If no children are being deleted, the gracePeriod is ignored)
That way, can set grace period of 0 if necessary.

[grzesuav]

hi @ikreymer wondering how it suppose to work - should it be part of Composite/Decorator controller CRD and be set on a given CR ? This would mean every delete would be made forced.

Also, what is the use care here ? In which cases it is desired ?

[ikreymer]

hi @ikreymer wondering how it suppose to work - should it be part of Composite/Decorator controller CRD and be set on a given CR ? This would mean every delete would be made forced.

Also, what is the use care here ? In which cases it is desired ?

I was suggesting above that this would work as an optional field in the Sync response, similar to how resyncAfterSeconds works, eg. forceDelete. If provided, and children are being deleted, the grace period/force option would be used, otherwise using the default grace period specified in a pod.

The idea is that some deletions may need to have more quickly then others, for example, if pods are being gracefully shutdown or canceled by the user. The use case would be to allow the user to cancel an operation and allow pods to be quickly shut down, bypassing the normal grace period. Since the default can already be set in the pod, I don't think it makes sense to make it part of the CR

[grzesuav]

I actually wonder how to handle that :
1️⃣ maybe make it a part of CRD spec - however it will be defined per GVK and static for all resources
2️⃣ make it a part of hook response, however, as deleted objects are not returned, it would be the same value for resource being deleted

[ikreymer]

I actually wonder how to handle that : 1️⃣ maybe make it a part of CRD spec - however it will be defined per GVK and static for all resources 2️⃣ make it a part of hook response, however, as deleted objects are not returned, it would be the same value for resource being deleted

I think 2), with same grace period value for all resources being deleted, is a reasonable compromise without adding too much complexity.
Since you can already set deletion order by choosing with children to delete, can delete children that need to be deleted quickly first, then others, etc... Combining that with resyncAfterSeconds gives pretty good control of deletion order, I think.

(For our use case, currently working around this by sending an out-of-band message to pods that they should exit immediately).

[ikreymer]

For example, if you have 3 pods, and want 1 deleted with grace period 0, and 2 and 3 delete with grace period 10,
seems like something like this could work?

1,2,3 -> {2, 3}, gracePeriodSeconds: 0, resyncAfterSeconds: 1
2, 3 -> {}, gracePeriodSeconds: 9

So child 1 will be deleted with grace period 0, pods 2 and 3 with grace period 9 after 1 second delay, so seems pretty close to the original goal of deleting 3 pods at same time but with different grace periods.

This is more complex then our use case, though.

[grzesuav]

what I actually meant in 2️⃣ - it will be the same value for all resources not returned as children in the response, just to clarify

[grzesuav]

closed by mistake

[ikreymer]

what I actually meant in 2️⃣ - it will be the same value for all resources not returned as children in the response, just to clarify

Yes, that's what I understood as well! But I think that still works, as in the example above, if you need different grace periods, you can still handle it with multiple responses as above before setting finalized: true, right?