GH ISSUE: https://github.com/openshift/oadp-operator/issues/1043

* This is a bolt on, not directly fixing velero
* Single threaded nature of velero, this makes it worse.
* Shawn's devil question
* non-admin user created backups will wait in new until

* Is wrapping velero w/ a non-admin velero-cr covering up the problem of correctly fixing velero's controllers to properly handle perf and multi-tenency

* Fixing the parallism problem is a possible prereq
* Alternatively we document that OADP will need to be installed into multiple namespaces
* Non-admin natively w/ velero would require new api's that handle rbac and would be very ugly.

* upstream vs. bolt on
* a bolt on may encourage better community practices

* cluster scoped operator

## Decision points
* Do we fix multithreaded velero now or wait. We agree that this is not tied to making the changes for multi-tenancy but may be neccessary for the UX
* Do we create a new controller/API's for multi-tenency such that it handles mapping to velero instances.
* Do we need to create a cluster scoped opeator that can install DPA's in individual namespaces.
* If there are more than one DPA's how does the multi-tenceny handle with DPA
* BSL's for multi-tenency are only for a individual namesapce.
*
* multiple velero pods
*

## Overview of usecase