[PR] Add "resuming" handlers for resources

[kopf-archiver]

A pull request by nolar at 2019-06-02 12:17:46+00:00
Original URL: zalando-incubator/kopf#96
 

Issue : #60

Description

Add the handlers for "resuming" (recalling? remembering?) an object in the operator:

@kopf.on.resume('zalando.org', 'v1', 'kopfexamples')
async def on_resume(**kwargs):
    loop = asyncio.get_running_loop()
    loop.create_task(a_long_running_coroutine(**kwargs))

    thread = threading.Thread(target=a_long_running_function, kwargs=kwargs)
    thread.start()

This complements the existing handlers for creation/update/deletion cases, and is triggered when the object is neither created, nor updated, nor deleted, but the operator has started/restarted, and needs to be aware of that object somehow.

As a side-note: I could not decide between "resume" and "recall" for proper naming. It is "resume", as it resumes some thread that was previously running in a now-dead operator. It is "recall", as it kind of "recalls" (remembers) the object: "ah, there is also such a thing with uid 123, which is not changed!". The naming can be changed before merged.

Types of Changes

• New feature (non-breaking change which adds functionality)
• Refactor/improvements
• Documentation / non-code

Review

• Tests
• Documentation

---

Commented by nolar at 2019-06-05 16:03:43+00:00
 

The first experience using it:

If I write

@kopf.on.create('zalando.org', 'v1', 'kopfexamples')
@kopf.on.resume('zalando.org', 'v1', 'kopfexamples')
def monitor_something(*, namespace, name, spec, logger, **kwargs):
    threading.Thread(...).start()

I expect that the thread is started either when a new object is created and the operator is running for some time, or when the object exists for some time and the operator has just restarted (i.e. either one is fresh new).

However, if the object was changed (e.g. its status) before the crash or restart, the UPDATE cause is detected, and the @kopf.on.update handlers are called. The @kopf.on.resume handlers are NOT called in case the object was changed — this breaks the intuitive expectations and semantics of a background thread starter (the original purpose of this handler).

Starting the threads from the UPDATE/DELETE handlers is not desired, as it means we have to keep track of the thread pool state per object — extra hassle.

The RESUME cause has to be handled even if the object has changed (but maybe not if deleted) — before or after the UPDATE handler in the same handling cycle.

PS: Or maybe there is no RESUME cause at all, and the @kopf.on.resume handlers are more like the event-handlers (@kopf.on.event), just happening on the initial object listing (maybe: and on creation), and not happening later.

---

Commented by nolar at 2019-06-06 18:49:28+00:00
 

Replaced by an alternative approach in #105, which feels more intuitive.