Bug 2007371

Summary:	[DR] [RFE] Ability to support dynamically named stateful sets generated PVC with ODF DR (e.g CrunchDB postgres operator)
Product:	[Red Hat Storage] Red Hat OpenShift Data Foundation	Reporter:	Jean-Charles Lopez <jelopez>
Component:	odf-dr	Assignee:	Shyamsundar <srangana>
odf-dr sub component:	ramen	QA Contact:	Elad <ebenahar>
Status:	CLOSED NEXTRELEASE	Docs Contact:
Severity:	unspecified
Priority:	unspecified	CC:	aclewett, bmekhiss, jespy, jmishra, kseeger, madam, mbukatov, muagarwa, ocs-bugs, odf-bz-bot, rcyriac, srangana
Version:	4.9	Keywords:	FutureFeature
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:	2022-06-29 14:32:09 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 Jean-Charles Lopez 2021-09-23 17:11:38 UTC

Description of problem (please be detailed as possible and provide log
snippests):
Currently the RamenDR operator and its components can only work if the PVCs are statucally named. This static behavior renders it inoperable with some DB operators that generate PVC names after creating a unique stateful set.


Version of all relevant components (if applicable):
4.9

Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?
Yes and No. Switched my testing to another type of test application but this new app is not as appealing for demo and video recordings we do in the BU to promote the product.


Is there any workaround available to the best of your knowledge?
Change the way the database is deployed for my app

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

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:
No

Steps to Reproduce:
1. Deploy the crunchy postgresql operator
git clone https://github.com/CrunchyData/postgres-operator-examples
oc apply -k /Users/JCL/OCS_AWS_Annette/postgres-operator-examples/kustomize/install
2. Setup ODR on both managed clusters and hub
3. Deploy application using ACM
Channel and subscription for https://github.com/jeanchlopez/application-samples
Branch keycloak-over-odf
Path keycloak-odf

Actual results:
Initial set of PVCs are detected by ODR
Initial set of PVs are configured for mirroring by ODR (replciation via rbd-mirror)
When failing over new PV/PVCs get allocated to the app on the secondary cluster

Expected results:
Initial set of PVCs are detected by ODR
Initial set of PVs are configured for mirroring by ODR (replciation via rbd-mirror)
When failing over the app on the secondary cluster can reuse the mirrored PVs


Additional info:

Comment 3 Benamar Mekhissi 2021-09-24 16:35:06 UTC

After looking at the crunchy postgresql operator code, it looks like the operator generates a unique PVC name if a PVC resource is not found. The first time the app is deployed, the PVC resource is created with a name in this format: "STS.Name + -pgdata". Where the STS.Name changes every time the app is restarted. When the app is restarted, the operator will find the PVC object already created (using labels and selectors for a match) and it uses the same name to bind to an existing PV.  If it doesn't find a PVC resource (which is what happens in a failover) then, it recreates the PVC resource with a new name (according to the format above) which would be different from the original name.  That will end up recreating the PV because the PV cliamRef will not match.

We have few ideas on how to handle this unstable naming of PVCs. We'll look at them in the next few days and we'll come up with a recommendation.

Comment 6 Mudit Agarwal 2022-05-31 14:55:01 UTC

Can we please create a Jira epic for this, if it doesn't exist already?