Sergey Vasilyev

What about creating the wrapping methods or returning the original methods on `__getattribute__`/`__getattr__`, and escalating the AttributeError if they are absent in the original wrapped object? Consider also the case...

@brainbreaker Sorry for slightly late response for almost a week. Yes, using either daemons or timers is the right way to do this task. They were actually designed for the...

Which version of Kubernetes do you use? As a quick-guess, try using explicit verbs instead of a star. ```yaml verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ``` The [RBAC...

Hello. Thanks for reporting. Can you please clarify the version? Are you sure it is version 0.23.2? I see this line: ``` File "/usr/local/lib/python3.7/site-packages/kopf/clients/watching.py", line 62, in streaming_aiter yield await...

One idea how this happens: Kopf uses a threaded executor of asyncio for synchronous handlers (declared with `def`, not `async def`). Python's threaded executor adds one more thread on every...

It did help. The thread count does not grow once the operator is started and used: it stays at 12 (10 were configured for the executor, 1 for the main...

Neither before, nor after, but _as part_ of create/update. Usually, the handlers are called in the order they are declared. Resume handlers are then just _mixed-in_ into the list of...

Both resume+update, or resume+create handlers will be called. However, if they point to the same function, they will be de-duplicated, and that function will be called only once. E.g.: ```python...

No, it is not possible at the moment to know when Kopf has finished the initial listing and started watching. And I'm not sure if this is at all conceptually...

The resuming will not happen after deletion or as part of deletion. if the object is gone (or is going to be gone soon), there is nothing to resume/monitor/handle. This...