Support preconditions
for Delete request
#545
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR introduces
preconditions
of Kubernetes delete requests. Thepreconditions
contain a uid and a resource version. When handling the delete request, the API server checks whether the object's uid and resource version match the ones provided by the request and returnsConflict
error if not. Kubernetes implements this feature here: https://github.com/kubernetes/kubernetes/blob/v1.30.0/staging/src/k8s.io/apiserver/pkg/storage/interfaces.go#L140-L153. Thepreconditions
is optional. Introducingpreconditions
mainly requires changes to the API server model (modeling the uid and resource version checking) and the shim layer (passing thepreconditions
tokube
).This PR also fixes some of the lemmas that are broken due to
preconditions
.Having
preconditions
allows us to use more restrictive deletion. This is useful to ensure no interference between controllers that manage pods --- when a controller decides to delete a pod that the controller believes belongs to itself, the controller should pass to thepreconditions
the resource version of the pod it observes. When API server handles the delete request, if the pod happens to be owned by a different controller, then the deletion will be invalidated (because the resource version must have already changed since the controller's observation) so that the controller won't interfere with the new owner of the pod.