---
# System prepended metadata

title: non-admin velero

---

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