Bug 2283820

Summary: [MDR][RDR] Discovered application pre-reqs require automated velero secret creation
Product: [Red Hat Storage] Red Hat OpenShift Data Foundation Reporter: Annette Clewett <aclewett>
Component: odf-drAssignee: Shyamsundar <srangana>
odf-dr sub component: ramen QA Contact: Annette Clewett <aclewett>
Status: CLOSED ERRATA Docs Contact:
Severity: unspecified    
Priority: high CC: kseeger, muagarwa, ocs-bugs, prsurve, srangana
Version: 4.16Flags: aclewett: needinfo-
Target Milestone: ---   
Target Release: ODF 4.16.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 4.16.0-124 Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-07-17 13:24:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Annette Clewett 2024-05-29 15:03:46 UTC
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:

Comment 3 Shyamsundar 2024-06-02 12:54:07 UTC
Upstream PR under review: https://github.com/RamenDR/ramen/pull/1413

Comment 5 Annette Clewett 2024-06-10 20:37:46 UTC
@prsurve 
I tested with ODF 4.16 build 124 and after installing MCO and creating the first DR policy, I found the noobaa object bucket secrets created on both managed clusters in the default OADP namespace openshift-adp using the velero secret format.

Managed clusters:
% oc get secrets -n openshift-adp
NAME                                       TYPE     DATA   AGE
v60f2ea6069e168346d5ad0e0b5faa59bb74946f   Opaque   1      5m51s
vcc237eba032ad5c422fb939684eb633822d7900   Opaque   1      5m42s

After creating the DPA custom resource in openshift-adp on both managed clusters and and applying a DR policy to Discovered app busybox, (created with "oc apply -k workloads/deployment/odr-regional-rbd -n busybox-discovered" using repo https://github.com/red-hat-storage/ocm-ramen-samples.git), I then proceeded to test Failover and Relocate . Both DR actions were successful.

Comment 6 Sunil Kumar Acharya 2024-06-18 06:45:26 UTC
Please update the RDT flag/text appropriately.

Comment 7 errata-xmlrpc 2024-07-17 13:24:04 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Important: Red Hat OpenShift Data Foundation 4.16.0 security, enhancement & bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2024:4591