Sergey Vasilyev

The in-memory caching is probably doable (in theory). I didn't try this yet. Usually, I keep the state on the objects themselves, not in memory (e.g. children's labels referring to...

`kopf==0.23rc1` was pre-released (see the [release notes](https://github.com/zalando-incubator/kopf/releases/tag/0.23rc1)). It fixes a lot of things with the on-resume handlers in #230: * There can be more than one on-resume handler (previously only...

Decided to go both ways (#233): Skip the on-resume handlers normally on deletions. But make it possible to mark them as deletion-safe (on the developer's responsibility). Pre-released as [`kopf==0.23rc2`](https://github.com/zalando-incubator/kopf/releases/tag/0.23rc2)

@Jc2k It was made internal-only for beginning (as part of this massive refactoring release). It is relatively easy now to add an extra field to the `ResourceMemory` class with arbitrary...

Some clarifications (I'll add them to the docs later): For _one specific operator_, only one pod should be running. Two pods will be conflicting with each other. _"One specific operator"_...

Example use-case: Automatically injecting the last-update timestamp when an object is created/updated, to implement the TTL-like cleanup of the stale objects (not updated for few weeks). * https://twitter.com/try_except_/status/1127484958258487297 * https://twitter.com/try_except_/status/1127494195881619456...

Taking the discussion from #49: @rosscdh asked: > I was thinking something like either another decorator or appending a `spec_validator` to the current decorator which if present would then validate...

@krish7919 Yes, having validating & mutating handlers is _intended_ for Kopf — i.e., the feature is in Kopf's scope. Beside, it is one of three remaining major features left to...

@Frankkkkk Yes, it is not an easy task for sure :-) Too many uncertainties. Before I can answer them, I need to play with admission hooks, so that I would...

Related: #23