-
Notifications
You must be signed in to change notification settings - Fork 87
Store handler progress data in an annotation, not the status subresource #321
Comments
I am running into this issue when watching a k8s service object. The patch command does not return any error, but no kopf status is added. Thus, no retry attempt is made in case of exceptions. |
I also had the same issues, but in an other context. |
Related to bug #308 where the same issue is visible for standard resources |
Workaround for persisting the handler return values:
Example usage with default annotation key:
Example usage with custom annotation key:
|
This was solved in #331 and follow-ups, and is available since |
Problem
As of
apiextensions.k8s.io/v1
it is much more difficult to create a CRD that allows unvalidated information, as an openapi schema is required for even the status subresource. Tracking the handler progress in an annotation instead of the status subresource means it's easier to use kopf to write operators for CRDs that we don't own.To define a wide-open status subresource in a v1 CRD, you can do the following:
Or for something more structured you can allow only the kopf property of the status subresource to be unvalidated as follows:
Proposal
Kopf already stores important metadata in annotations including
kopf.zalando.org/last-handled-configuration
andkubectl.kubernetes.io/last-applied-configuration
. Setting up the state.py mechanism to similarly use an annotation instead of the status subresource for its progress data should, I hope, be relatively straight-forward.For resources whose CRDs can be altered, the other mechanisms to allow status.kopf.progress is an okay work-around. But the v1 schema enforcement means that kopf can't store its progress data there any more if the CRD cannot be altered.
Checklist
The text was updated successfully, but these errors were encountered: