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

test: Optimistic Locking integration test suite #61

Merged
merged 1 commit into from
May 11, 2022

Conversation

manusa
Copy link
Owner

@manusa manusa commented May 11, 2022

Description

The OptimisticLockIT test suite verifies the Kubernetes API behavior when dealing with the metadata.resourceVersion field.

The K8s API doesn't provide an idempotent behavior when performing PUT requests as stated in the API conventions document (however, it does for certain resources):

https://github.com/kubernetes/community/blob/00e50166cc289d5afb22c2159640134fd8d72c58/contributors/devel/sig-architecture/api-conventions.md

Otherwise, PUT expects the whole object to be specified. Therefore, if a field is omitted it is assumed that the client wants to clear that field's value. The PUT verb does not accept partial updates. Modification of just part of an object may be achieved by GETting the resource, modifying part of the spec, labels, or annotations, and then PUTting it back. See concurrency control, below, regarding read-modify-write consistency when using this pattern. Some objects may expose alternative resource representations that allow mutation of the status, or performing custom actions on the object.

In the Concurrency Control section, this point is not that clear:

If resourceVersion is included with the PUT operation the system will verify that there have not been other successful mutations to the resource during a read/modify/write cycle, by verifying that the current value of resourceVersion matches the specified value.

The wording here is not that clear and suggests that the resourceVersion field can be omitted to bypass optimistic locking. That may be the reasoning behind the inconsistent behavior of PUT operations depending on the resource.

Related

/cc @shawkins @csviri

Validates K8s API behavior regarding PUT requests and the metadata.resourceVersion field
@manusa manusa merged commit 4159267 into master May 11, 2022
@manusa manusa deleted the test/optimistic-locking branch May 11, 2022 09:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant