Way to identity resume operation inside the handler

[sajuptpm]

Question

Any way to identity resume operation inside the handler

use case: I want to skip some business logic in the handler, If it is resume operation, I have only one handler with on.create decorator and not using on.resume decorator. Operator resumes the on.create handler if there is a pod restart, right ? I want to identify this pod restart or resume operation inside the handler. Please let me know if it is not clear., thanks

[nolar]

Sorry, I didn't get the setup. A code snippet can be helpful here.

If you meant 2 decorators for the same function, you can try using handler parametrisation: https://kopf.readthedocs.io/en/stable/kwargs/?highlight=param#std-kwarg-param

[sajuptpm]

@kopf.on.create(---)
def create_app(name, spec, patch, retry, **kwargs):
   line-1
   if not resume:
      #dont want to execute this logic on resume or operator reboot during create
      line-2
      line-3
   line-4

[nolar]

Operator resumes the on.create handler if there is a pod restart, right?

Well, as far as I know, no. If the pod is restarted, it is the same pod, so it will be on-update probably (if its on-creation was handled before). However, if this is a new pod according to some Kubernetes controller's logic (Deployment/Job/CronJob/etc), it will be treated as a new one, i.e. on-creation will be handled. You can see that by the pods' names.

The following steps depend on which goal you want to reach.

If it is something like "only handle the first pod owned by the same parent Deployment/Job", I would look into in-memory indexing combined with when= filter of pods' on-creation handler.

If it is something like "if the creation handler fails at line-2 & line-3, then do not retry line-1 ever again", I would look to splitting the handler to 4 handlers (for 4 lines in your sample) or to using 4 subhandlers. The atomic units of work in Kopf are handlers/subhandlers: they either succeed in full, or are retried in full (actually, it comes from a Python limitation).

dont want to execute this logic on resume or operator reboot during create

The on-creation handlers will not be executed as on-resume on operator reboot (or they shouldn't be, unless it is a bug).

However, the on-creation logic will be executed for all new resources created during the operator's downtime — there is no way to distinguish those created in downtime and those created at runtime — they all look new to Kopf.