You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Patch custom/built-in resources with status declared as a sub-resource via a separate URL — instead of being a field of a resource itself.
Description
Previously, Kopf always assumed that custom resources and built-in resources store status as part of the object (which was the case in early Kubernetes versions).
But this has changed since sub-resources were introduced. While it was not a big problem for custom resources, where the developers could define the sub-resources and skip "status" there, it became a problem with some built-in resources like "storage.k8s.io/volumeattachments", which have the status defined as a sub-resource and operator developers cannot control it.
As a result, when Kopf was patching the object itself with {"status": ...} payload, the status was lost, and the reaction cycle did not continue, so the handlers were skipped.
With this PR, Kopf discovers and respects the status-as-a-subresource both in custom and built-in resources, and patches them accordingly: either as a whole object with a status field (if not a sub-resource), or separately for object & status endpoints (depending on the patch's content).
The latter aspect can cause for 2 PATCH requests to be made when both the body (e.g. metadata) and the status has to be updated — when previously it was only 1 (but did not work with this kind of resources at all).
From the user perspective, a wider set of built-in resources can be handled now, and their custom resources can also have status declared as a sub-resource (if they wish so).
What do these changes do?
Patch custom/built-in resources with status declared as a sub-resource via a separate URL — instead of being a field of a resource itself.
Description
Previously, Kopf always assumed that custom resources and built-in resources store status as part of the object (which was the case in early Kubernetes versions).
But this has changed since sub-resources were introduced. While it was not a big problem for custom resources, where the developers could define the sub-resources and skip "status" there, it became a problem with some built-in resources like "storage.k8s.io/volumeattachments", which have the status defined as a sub-resource and operator developers cannot control it.
As a result, when Kopf was patching the object itself with
{"status": ...}
payload, the status was lost, and the reaction cycle did not continue, so the handlers were skipped.With this PR, Kopf discovers and respects the status-as-a-subresource both in custom and built-in resources, and patches them accordingly: either as a whole object with a status field (if not a sub-resource), or separately for object & status endpoints (depending on the patch's content).
The latter aspect can cause for 2
PATCH
requests to be made when both the body (e.g. metadata) and the status has to be updated — when previously it was only 1 (but did not work with this kind of resources at all).From the user perspective, a wider set of built-in resources can be handled now, and their custom resources can also have status declared as a sub-resource (if they wish so).
Issues/PRs
Type of changes
Checklist
CONTRIBUTORS.txt
The text was updated successfully, but these errors were encountered: