# Client-side operand deletion

## Summary
Currently when a user deletes an operator, by deleting the CSV, the operands (Custom Resources) of that operator remain on-cluster. There is no automatic cleanup of operands when the operator is removed.

Providing a server-side operand deletion feature was explored in [the following enhancement](https://github.com/operator-framework/enhancements/blob/master/enhancements/olm-deletes-operands.md), where the CSV author could indicate that OLM should delete operands upon deletion of the CSV via a finalizer. After going through the implementation, there were a lot of risks discovered in implementing the deletion feature this way, some of which were outlined in [the following doc](https://hackmd.io/dM5k3slkTna64NNueushkA). Due to the multitenant and transient nature of CSVs, there was no clear way to prevent accidental data-loss in the case of deletion.

As a result, instead of OLM performing operand deletion, this design doc describes an imperative client-side approach, where a user can discover and delete operands via standard client tooling like kubectl or the console.

## Goals
* Provide functionality to list all CRs associated with a particular operator CSV on-cluster. This will live in the existing [kubectl operator plugin](https://github.com/operator-framework/kubectl-operator).
Enable the above command to be piped to another command that actually issues the delete, via kubectl or oc. A demo of the intended functionality can be found here https://asciinema.org/a/Q01CKZCauu8IZizk9WbCYQP5I. The command can be `kubectl operator list-custom-resources <operator package> -n <namespace>`
* Add a command to delete the operator and related operands such as `kubectl operator delete <operator> --delete-crs`
* Enable the operator-sdk to implement similar functionality, so that downstream Openshift users also have access to operand deletion
* Enable the console to delete operands via the UI, as laid out in the mock draft http://openshift.github.io/openshift-origin-design/designs/administrator/olm/uninstall-operator-delete-operands/

## Non-Goals
* Ensure "safe" operand deletion. The imperative approach will warn the user that deletion is risky, but OLM or other componenets are not responsible for the state of the cluster after deletion. Docs should also reflect the caveats involved, so users are aware of the risks
* Removal of CRDs upon deletion. This design covers CR deletion only.
* Modify the existing `kubectl operator uninstall` command -- that command is more destructive than the proposed `kubectl operator delete`

## Caveats
* The number of CRs an operator has is potentially unbounded, and can appear across multiple namespaces or all namespaces on-cluster. Any client side tool that enables the deletion of CRs should be programmed as to be able to handle large batches of CR instances.
* There is no way to ensure deletion will not affect other operators or users on the cluster, and there is no way to un-delete CRs.

### Implementation Details
* Listing CRs can be accomplished using the meta client in client-go which can return ObjectMeta information such as Name/Namespace only. This will considerably lighten the load on the api-server when issuing list queries.
* Finding the operator will use the new OperatorV1 API. This API needs a package and namespace to return a unique operator, unless it is cluster-scoped. Simply accepting a package name could return multiple operator objects from the API. The expected flow would be to expect a namespace argument for namespace scoped operators during deletion, and erroring if more than 1 operator object is returned from the Operator API. From an operator object the relevant CSV can be found.