Client: Add DeleteCollection

[alvaroaleman]

It would be awesome if client.Writer was extended with DeleteCollection to allow deleting a set of objects with one call.

/kind feature

[DirectXMan12]

there's a WIP PR for this (#324 )

[MadVikingGod]

I have been working on this and Could use a bit of feedback. How did you invision using this call?

I have tried two different forms, one where there is an explicit DeleteCollection() added to the client interface, and one where the presence of CollectionOptions in the Delete() call does the same logic.

The one thing that I fear, which might be unneeded, is that in both cases I only use obj's type to determine what to delete. This means that if you pass an object and a CollectionOptions that won't match the object it won't delete that object.

For example:

	obj := &corev1.Pod{
		ObjectMeta: metav1.ObjectMeta{
			Name: "foo",
			Namespace: "bar",
			Labels: map[string]string{
				"app": "stuff",
			}
		}
	}
	c.Delete[Collection](context.TODO(), obj, client.CollectionOptions(
		client.InNamespace("bar"),
		client.MatchingLabels(map[string]string{
			"app": "otherStuff",
		}),
	))

This will delete any Pod in the bar namespace, with the label app=otherStuff, but it won't delete the original obj. If this call was Delete() that feels wrong, but it seems reasonable for DeleteCollection.

[alvaroaleman]

Sorry for the late feedback, I was on vacation.

I have tried two different forms, one where there is an explicit DeleteCollection() added to the client interface, and one where the presence of CollectionOptions in the Delete() call does the same logic.

I personally would prefer DeleteCollection as it is more explicit

The one thing that I fear, which might be unneeded, is that in both cases I only use obj's type to determine what to delete. This means that if you pass an object and a CollectionOptions that won't match the object it won't delete that object.

What is the reason to even have both an obj and a CollectionOptions parameter? Wouldn't it make sense to make obj part of CollectionOptions?

[MadVikingGod]

The reasoning behind having a different object and collectionOptions, or ListOptions, is that every delete api in kubernetes is tied to a GVK. The obj gives us the kind of things we are deleting, the DeleteOptions carry things like if the deletes should propagate, and the CollectionOptions are your label selectors.

Just to explore this a bit further, and this is just me thinking out loud, we could remove the obj from the DeleteCollection's signature, and add something like HasGVK(obj runtime.Object) DeleteOption. Yeah, thinking on this, because the Object's GVK is a required portion for the API I think it would better inform consumers of this change.

I don't think there is an easy, and safe, way to get the GVK of a runtime.Object, but How would something like DeleteCollection(ctx context.Context, gvk schema.GroupVersionKind, opts ...DeleteOptionFunc)? So the use of it would looks like c.DeleteCollection(context.TODO(), obj.GroupVersionKind(), CollectionOptions...)

[DirectXMan12]

we have machinery inside CR to do runtime.Object <--> GVK (it generally involves runtime.Scheme, except for unstructured).

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[alvaroaleman]

This was implemented in #447