Delete: needs more preconditions

[lavalamp]

Today you can use UID as a precondition for delete; this allows you to avoid deleting an object that has been replaced with an object of the same name.

As reported by @fasaxc on slack, there's also a need to ensure a delete fails if an unobserved change happens to an object. This could be implemented as either an RV or a Generation precondition.

Scenario:

1. A observes object foo and sends a delete request.
2. B observes object foo and modifies it in a way that would have prevented its deletion.
3. A's delete request happens to arrive afterwards; the object is deleted and B's change is lost.

/sig api-machinery

[ajatprabha]

@lavalamp I'd like to work on this issue.

[lavalamp]

@ajatprabha Go for it!

[seh]

Related:

• Support "Delete" and "Get" via UID or with UID as a precondition #20572
• Document API architectural approach for soundness and consistency website#41954

[krmayankk]

Are we saying that , if I get an object, store its resourceVersion and then issue a delete on the resourceVersion for that object , even though the object has been modified and hence its resourceVersion changed, the delete still succeeds ?

[ajatprabha]

@krmayankk I think there is no RV based precondition check on delete. Only UID based check is there.

kubernetes/staging/src/k8s.io/apiserver/pkg/registry/rest/delete.go

Lines 79 to 82 in 0c2613c

	// Checking the Preconditions here to fail early. They'll be enforced later on when we actually do the deletion, too.
	if options.Preconditions != nil && options.Preconditions.UID != nil && *options.Preconditions.UID != objectMeta.GetUID() {
	return false, false, errors.NewConflict(schema.GroupResource{Group: gvk.Group, Resource: gvk.Kind}, objectMeta.GetName(), fmt.Errorf("the UID in the precondition (%s) does not match the UID in record (%s). The object might have been deleted and then recreated", *options.Preconditions.UID, objectMeta.GetUID()))
	}

I'm a little confused when you say issue a delete on resourceVersion for that object. Do you mean like delete the object with old stored RV? In that case, I think currently the delete succeeds as I can't find a check.

[ajatprabha]

@lavalamp I'm looking at #22965 to see which places need precondition checks. Will a simple Preconditions.ResourceVersion check suffice to solve the issue here? Also, how will a Generation precondition work if it is to be used?

[lavalamp]

RV precondition: only delete the object if its current RV equals the specified one.

Generation precondition: only delete the object if its current metadata.Generation equals the specified one.

Either one works, the generation one is more tolerant of random status updates. There's possibly room in the world for both.

@deads2k might have an opinion?

If we're going to have more than 2 or three of these things we probably need to make a general mechanism :/ But I think people can use RV or Generation preconditions to stand in for an arbitrary check, so if anything deserves a top level precondition, it'd be those.

[lavalamp]

Thanks, @ajatprabha!

[krmayankk]

This is good to know, I thought the RV based update/delete worked and would always result in conflict if RV changed. I wonder where do these kinds of changes get documented . May be worth an entry in the api conventions doc?