Add alternative CSI driver installation method
@@ -202,6 +202,59 @@ Kubernetes 1.21 is current upstream target for removal of in-tree cloud provider
## Alternatives considered
+As an alternative approach, we are considering deploying CSI drivers using a central operator, as opposed to deploying them via dedicated operators like we presented before.
+
+Ideally, **cluster-storage-operator** (CSO) would play the role of installing the CSI drivers. In addition to deploying the default StorageClass for the cluster, like it currently
+does, CSO would also deploy everything necessary for the StorageClass to be functional: the CSI driver.
+
+This how the workflow would look like:
+
++--------------------------+ +--------------------------+ +--------+
+| | | | | |
+| cluster-version-operator |+-->| cluster-storage-operator |+--> | driver |
+| | | | | |
++--------------------------+ +--------------------------+ +--------+
+
+And this is how the workflow of our previous approach would look like:
+
++--------------------------+ +--------------------------+ +---------------------+ +--------+
+| | | | | | | |
+| cluster-version-operator |+-->| cluster-storage-operator |+-->| csi-driver-operator |+-> | driver |
+| | | | | | | |
++--------------------------+ +--------------------------+ +---------------------+ +--------+
+
+
+### Installation
+
+1. During installation, cluster-version-operator (CVO) starts CSO.
+2. CSO detects the underlying cloud platform and creates the CSI driver CR for that cloud platform, e.g., `AWSEBSDriver` for AWS.
+3. In addition to that, CSO creates a new controller to act on that CR.
+4. This controller's job is to sync the CSI driver for that given cloud. In other workds, it deploys the CSI driver and everything it else needs to work, i.e.,
+cloud credentials, RBAC, Deployment, DaemonSet, CSIDriver and StorageClass objects.
+5. The controller report the progress of the operand (CSI driver) in the CR deployed in step 2 above.
+6. CSO starts a new controller whose job is to watch all CSI drivers' CRs and reports back their status ("Progressing", "Degraded", "Available", ...) in CSO's ClusterOperator status.
+
+### Upgrade from OLM-managed operator
+
+CSO will deploy the CSI drivers in the `cluster-storage-operator` namespace. In OCP 4.5, AWS and Manilla operators deploy their operators in their respective namespaces,
+so we might end up with two CSI drivers installed in the cluster.
+
+There are two alternatives to overcome this problem.
+
+#### Alternative 1
+
+Document that the administrator needs to uninstall the 4.5 CSI Driver operator before upgrading to 4.6.
+
+The downside of this alternative is that we don't support an upgrade path for the operator.
+
+#### Alternative 2
+
+When started, CSO detects that there is a AWS or Manilla operator installed by OLM and remove it. Once the operator is gone, CSO deploys the new CSI driver.
+
+In this case, it's important that the CSI driver's StorageClass deployed by CSO has the same name as the one deployed by the CSI driver operator.
+
+This alternative migh impose another problem: AWS EBS CSI Driver Operator doesn't remove the operand if there are volumes using the CSI driver.
+
### Installation via OLM
We explored possibility of installing CSI driver operators via OLM. This has been proven to be difficult, not because
