Replacement for deleteExisting behavior.

[shawkins]

Is your enhancement related to a problem? Please describe

deletingExisting was removed to help streamline the api interfaces (it wasn't universally available for Resource) and because the implementation wasn't based upon exact deletion tracking - which is now possible that delete can return the deletion list.

Describe the solution you'd like

In kubectl apply and replace have a force option. That is relevant to our create, replace, and createOrReplace operations. It would also be applicable to some of the patch methods, which allow for our current server side apply behavior.

One option is to provide a higher level blocking delete operation #3246 - similar to the logic in kubectl we would track by uid is possible what resources were deleted to make sure that intervening creates don't cause indefinite waits.

That could look like Deletable.forceDelete returning a CompletionStage<List> - that would give the user flexibility in how long to wait. The downside is that it's not fluent.

Another option is to add a boolean force parameter to the given affected methods - resource.replace(true) - that has the downside of affecting quite a few methods.

Finally to provide the force option via a method - resource.force().create() - we'd need another interface used at both ListVisitFromServerWritable and WritableOperation that adds a force method which would need a new interface to allow for CreateOrReplaceable or patch methods to then be called. It's that last part about patch methods that make this a little less appetizing of a solution - until we have a higher level method for server side apply, I don't think this one is a great option.

Describe alternatives you've considered

No response

Additional context

No response

[shawkins]

Based upon the initial team call feedback the force() method option was the favorite - it's the closest to kubectl, it's the simplest for users, and we'll have a server side apply dsl with #4531. That outweighs the blocking nature. The assumption is that later we'll offer non-blocking variants of the operation methods, like create.