Support multi-step deletion process #850
Comments
|
Hello. This is the default behaviour of the deletion handlers, as of any other handlers if For example: import kopf
@kopf.on.delete('kopfexamples')
def delete_fn(retry, logger, **_):
if retry < 3:
raise kopf.TemporaryError("not yet", delay=5)
logger.info('DELETED')I'm not sure what happened at the end of the log here — I'll check it later. But generally, the delayed deletion worked: it took 15 seconds (attempts 0, 1, 2 caused a delay by 5 seconds, attempt 3 succeeded).
This might be a problem and Kopf has some known limitations to detect that. Kubernetes does not delete the resources, it marks them for deletion by setting the This is how Kopf understands that the resource is being deleted — by the existence or absence of the deletion timestamp: if the timestamp is set, it calls on-delete; if not set, then on-update (or if the last-handled-state is not set, then on-create, but this is not the case here). In other words, Kopf cannot properly detect if the change of a field was a relevant update when the object is in the state of deletion. However, you can notice that: @kopf.on.delete('kopfexamples')
def delete_fn(retry, logger, diff, **_):
logger.info(f"{diff!r}")
if retry < 3:
raise kopf.TemporaryError("no yet", delay=5)
logger.info('DELETED')The detection is not immediate, as usually that handler is marked as temporarily failed and it will wait until is retry time comes. The proper solution for this issue would be the idea from #9 / #163 — remembering which handler processed which state of the object — but I failed two times with that already. I will think about how Kopf should treat the object changes that happen during its deletion, and whether they should be considered updates (which seems reasonable). And if so, how should Kopf separate the "updates processing" from the "deletion processing". For now, I suggest considering this as a known limitation of the framework and looking for workarounds: e.g. |
|
I thought about using a TemporaryError here, but it did not seem appropriate to have the logs reporting errors when it wasn't an error condition. I suppose that would be a separate feature request? A way to indicate log level with a TemporaryError or other exception class for reporting a non-error condition that should still result in a retry? Also, in my use case the delay isn't quite appropriate. It receives an outside event. The way the process works is that it kicks off a process in an external system and then receives a callback from that system via a flask api that runs along side the kopf operator. The callback updates the resource state and then it responds to the update event. At present I have this working with |
Problem
I want to use a multi-step deletion process where deletion triggers activity outside of the operator which then calls back to allow completion of the delete.
Proposal
It should be possible for an
on.deletehandler to return an explicit value or raise a special exception that indicates that no error occurred but delete processing is not yet complete. This would indicate that finalizers should not be removed. If a multi-step delete process is indicated on theon.deletehandler then it should also run for any updates to the resource.Code
... or using a special exception ...
Additional information
No response
The text was updated successfully, but these errors were encountered: