Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PR] Patch status as a sub-resource if defined so #313

Closed
3 of 5 tasks
kopf-archiver bot opened this issue Aug 18, 2020 · 0 comments
Closed
3 of 5 tasks

[PR] Patch status as a sub-resource if defined so #313

kopf-archiver bot opened this issue Aug 18, 2020 · 0 comments
Labels
archive enhancement New feature or request

Comments

@kopf-archiver
Copy link

kopf-archiver bot commented Aug 18, 2020

A pull request by nolar at 2020-02-13 20:02:53+00:00
Original URL: zalando-incubator/kopf#313
Merged by nolar at 2020-02-20 11:20:53+00:00

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

Issues: #308 closes #119

Type of changes

  • New feature (non-breaking change which adds functionality)

Checklist

  • The code addresses only the mentioned problem, and this problem only
  • I think the code is well written
  • Unit tests for the changes exist
  • Documentation reflects the changes
  • If you provide code modification, please add yourself to CONTRIBUTORS.txt
@kopf-archiver kopf-archiver bot closed this as completed Aug 18, 2020
@kopf-archiver kopf-archiver bot changed the title [archival placeholder] [PR] Patch status as a sub-resource if defined so Aug 19, 2020
@kopf-archiver kopf-archiver bot added the enhancement New feature or request label Aug 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
archive enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

0 participants