annotations on handler failure?

[InvisibleFunction]

It looks like when a handler encounters an error an annotation is created with some info. Can anyone point me at documentation around this feature?

When is it triggered? Does the absence of this annotation mean a successful handler run? There's a "success" key, can this ever be "true"?

[nolar]

It is done by the progress storage. It can be true if there are 2+ handlers, one has succeeded, but others have failed or not started yet.

All these are temporary states stored by Kopf for its own consumption. Annotations are used as a storage to work “out of the box” in 100% cases. If these annotations are not desired, users can implement & configure their own key-value storage of any kind (incl. filesystem).

https://kopf.readthedocs.io/en/stable/configuration/#handling-progress

[InvisibleFunction]

Thanks for the explanation, that’s helpful! I guess I should say what I’m actually trying to do. I have a pipeline that PATCHes one of my custom resources. It would be helpful if it could see when the handler run was not successful so it could quickly get this information back to the user.

Right now I’m looking for this annotation with success=“false” as a sign of an error and no annotation as a sign of success. I’d be curious if you had any better ideas offhand. Thanks!

[nolar]

Your domain-specific status should be added explicitly by you. You should not rely on Kopf’s internal annotations as they might change any time without warning.

The best way seems to wrap your risky logic with try-except-else-finally and put the status/annotations into the “patch” kwarg inside the handler, then reraise the original error.

[InvisibleFunction]

I totally get that I should not rely on the internal annotations, but in this case I currently can't detect the failure, so detecting it some of the time is an improvement in my opinion.

I'm wondering if I'm doing something that's not quite best practices here. The operator owns these resources, but there is a field on them that is "owned" by this pipeline, so the operator isn't doing the patch. The pipeline uses kubectl to PATCH the resource and then the operator takes action with kopf.on.update.

Perhaps I need to modify my handler to catch some exceptions and make this information available somewhere.

[nolar]

You might as well see it in Kopf’s logs, especially if executed with “-v”.

[InvisibleFunction]

Certainly, but the pipeline my users are using only has limited kubectl access to the resources.