Sergey Vasilyev

@joberdick-rcd Yes, I was not able to reproduce it. Everything works fine for me. I used K3s 1.21.9+k3s1, Python 3.9.7, Kopf 1.35.3. The virtualenv was originally clean and populated via...

It's an interesting usage scenario. I never thought of multiple webhook servers in combination with peering. Technically, freeze is implemented by disconnecting from all API calls and streams at all....

> so that you could run multiple copies without all of them reacting to changes You understood it right — that is the goal. However, peering was implemented long before...

Generally, no. Operators are regular Kubernetes API clients: they watch & patch only, strictly via the API. As long as the API works, Kopf will work too. But old versions...

> Handling cycle is finished, waiting for new changes > Removing the finalizer as there are no handlers requiring it The messages are sent via Python logging facilities. Specifically, these...

> When the deletion handler exits successfully, kopf tries to patch the service to remove its finalizer, but adds back the AWS load balancer finalizer. Can you please clarify here?...

> I have a handler that us watching for `batchv1.jobs` resources and it needs to update the CR from that event handler. > I don't think returning a dict from...

First, making own client requires effort and time investment, which I cannot afford. Especially for later maintenance. Second, making own client implies that it is different or better than the...

Diffbase is stored only when there is need for that — i.e. when on.create/update/delete/resume handlers exist for the resource kind. With on.event/index/timers/daemons, diffbase is not stored. The existence of diffbase...

Correct, with notes. "Correct": Kubernetes has no such feature with change detection and new-vs-old object distinction. Kubernetes capabilities end with `@kopf.on.event()` low-level handlers. The change detection is Kopf's own addon,...