Description of problem (please be detailed as possible and provide log
snippests):
The velero Backup API is used for Discovered apps to backup kube-objects to the DR created noobaa buckets also used by ramen to upload PVC/PV/VRG metadata. Velero needs to have access to these object buckets using secrets created in the OADP namespace. The velero secrets created in the OADP namespace must have the same AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in order to access the ramen noobaa buckets. Automating this secret creation in the OADP namespace guarantees that there are no operator errors and makes it much easier for users of Discovered apps to protect these new category of applications. 


Version of all relevant components (if applicable):
ODF 4.16 (build 108)
ACM 2.10.3
OCP 4.16

Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?
Yes, attempting to create velero secrets manually using bucket creds from ramen secrets is very difficult and error prone.

Is there any workaround available to the best of your knowledge?
Yes, document how to do lengthly process and hope it works correctly.

Rate from 1 - 5 the complexity of the scenario you performed that caused this
bug (1 - very simple, 5 - very complex)?
4

Steps to Reproduce:
1. Install OADP 1.3 operator on each managed cluster
1. Create RDR or MDR test env
2. Create DPA in OADP namespace on each managed cluster
2. Create application manually on one of the managed cluster
3. Use Discovered application UI to assign DR policy to new application


Actual results:
Secrets in OADP namespace to access ramen noobaa object buckets do not exist and must be created by user manually for kube-object backup to succeed.

Expected results:
Secrets in OADP namespace to access ramen noobaa object buckets do exist (automatically created when DR installed) and kube-object backup works as expected with no additional effort from user.

Additional info: