Bug 2319824

Summary: [RDR] Replication via Volsync requires PVC to be mounted before PVC is synchronized
Product: [Red Hat Storage] Red Hat OpenShift Data Foundation Reporter: astreit
Component: odf-drAssignee: Benamar Mekhissi <bmekhiss>
odf-dr sub component: ramen QA Contact: krishnaram Karthick <kramdoss>
Status: NEW --- Docs Contact:
Severity: high    
Priority: unspecified CC: bmekhiss, muagarwa
Version: 4.17   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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 astreit 2024-10-18 18:08:43 UTC
Description of problem (please be detailed as possible and provide log
snippests):
In the context of replicating a Protected Application volumes via Volsync within the context of ACM Disaster recovery/Enroll Application/Discovered Application, Volsync requires the every PVC to replicated to be mounted before synchronizing the volume.

For Cloud Pak for Data (and Watsonx family of offerings deployed on Cloud Pak for Data platform) a number of PVC's are created upon application deployment but only mounted on an extended interval via CronJob/Pod.

The described behavior is not expected and not consistent with replication via ceph data mirroring which does not depend on, require PVC's to be mounted.


Version of all relevant components (if applicable):


Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?
Yes, the Protected Application must be modified/adjusted to be successfully replicated.

Is there any workaround available to the best of your knowledge?
Create a Deployment to mount the unmounted PVC's, however this causes the CronJob/Pod to fail as the PVC's in question are RWO.


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

Can this issue reproducible?
Yes

Can this issue reproduce from the UI?
Yes

If this is a regression, please provide more details to justify this:


Steps to Reproduce:
1.
2.
3.


Actual results:


Expected results:


Additional info:

Comment 2 Sunil Kumar Acharya 2024-10-21 09:19:54 UTC
Moving the non-blocker BZs out of ODF-4.17.0. If this BZ is a blocker, Please feel free to propose it with justification note.