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:
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.
Can we please create a Jira epic for this, if it doesn't exist already?