In fact, what we need to do here:

1. extend "DeleteOptions" object to contain additionally LabelSelector and FieldSelector (similarly to ListOptions)
2. Change the pkg/apiserver/resthandler.go DeleteResource method so that it supports also deletion when name is not specified (and then uses selectors from options instead)
3. Change the interface of registry so that it supports also deleting all resources satisfying the selector (either pkg/registry/generic/etcd/etcd.go Delete method or adding new "DeleteWithLabels" method)
4. Implement the proper deletion code in the registry.

Let's not add a field selector to DeleteOptions for now, please. I'm not convinced that's a pattern we want to encourage, and power is hard to take away.

For these bulk mutations, we need to figure out how to make them work asynchronously, even in the presence of TCP disconnects and apiserver failures. For instance, Namespace deletion (#7372) can record the fact that it's deleting in the DeletionTimestamp of the Namespace resource. We probably need to create a Deletion controller with the specified label selector in order to drive the process until completion. We should have an API that would allow users to discover/confirm that a such deletion operation was in progress. Perhaps this suggests we should reintroduce an Operation API, only properly scoped (e.g., by namespace and kind) and persisted.

cc @derekwaynecarr @smarterclayton

@wojtek-t - isn't the solution to bulk resource deletion of events in a namespace is to not delete them one by one in etcd and instead do a single delete call to the parent folder?

/registry/events/namespaceA/event1
/registry/events/namespaceA/event2
...

i.e. we would just do a DELETE /registry/events/namespaceA which is what is implemented in #7372 ? To me that seems the ideal solution for the problem identified.

@wojtek-t - is the concern the time to wait or the actual time to remove from etcd? I don't see how adding a label selector makes the actual time to purge from etcd better versus the single bulk delete of the collection.

does a collection delete result in the proper watch events for the individual items deleted?

@derekwaynecarr - it's definitely enough for my usecase motivation. I think that what @bgrant0607 suggested is to have something more generic.

@liggitt - yes

I guess rather than something generic that still needs to result in N calls to etcd to satisfy for deleting N items, I would like to get the basic case of making 1 call to delete N items from etcd right. The only pattern for that now is collection delete which works well in namespace case, but longer term it would be good if we can pass multiple keys to delete to etcd. I need to review the v3 api for etcd, but I thought that pattern was there.

In the v3 etcd API there will be support for transactions. So you will be able to delete multiple objects within a single transaction (which will effectively be a single call).

Probably we should just wait for that API to implement the label selector filtering, then.

Probably we should just wait for that API to implement the label selector filtering, then.

SGTM

For now (after 1.0) it would be enough to have @derekwaynecarr #7372 merged.

Just as an update - we already have a support for collection deletion at the apiserver level (supporting selectors, delete options etc.).
The only missing thing is that it's currently implemented naively in apiserver, because of etcd v2 limitations. Once we are migrated to etcd v3, we should just improve the implementation and close this issue.

@wojtek-t do we need to keep this issue open then? Right now I'd prefer to open specifics on the most recent changes.

I'm fine with that and closing the new one.