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):
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.
Description
The
OptimisticLockITtest suite verifies the Kubernetes API behavior when dealing with themetadata.resourceVersionfield.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
In the
Concurrency Controlsection, this point is not that clear:The wording here is not that clear and suggests that the
resourceVersionfield can be omitted to bypass optimistic locking. That may be the reasoning behind the inconsistent behavior of PUT operations depending on the resource.Related
is invalid: metadata.resourceVersion: Invalid value: 0x0: must be specified for an update{"reason":"FieldValueInvalid","message":"Invalid value: 0x0: must be specified for an update","field":"metadata.resourceVersion"}/cc @shawkins @csviri