HackMD
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
*
