Supported Applications === Ramen protects Applications’ Persistent Volumes across a set of Managed Clusters. In order for Ramen to determine what PVCs to protect, a Label Selector must be provided to it. This is the same label selector found in the DRPC resource. ``` spec: ... pvcSelector: matchLabels: appname: busybox ``` Hence, Ramen will protect any PVC that matches the label. In this example, any PVC with label `appname: busybox` will be protected. PVC Creation/Deletion --- We have tested applications with 3 methods of PVC creation/deletion. - PVCs created statically - PVCs created by Custom Operators - PVCs created by StatefulSet Controller 1. PVCs created statically We have mostly tested with statically create PVCs. A PVC object is created from a static manifest file describing the PVC. An example of this is found here: https://github.com/RamenDR/ocm-ramen-samples/tree/main/busybox In that example, busybox Pod is created when the busybox-pod.yaml is applied by ACM Subscription. The Pod uses the PVC to request physical storage. The PVC is also created when busybox-pvc.yaml is applied by ACM Subscription. This type of application has been tested and verified to work reliably. 1. PVCs created by Custom Operators The Postgres Operator from Crunchy Data is an example of an operator that automatically manages PostgreSQL clusters. It creates PVCs dynamically, and the name of the PVCs that it creates follows a pattern that can’t be regenerated in the other cluster when the failover takes place. We have a work-in-progress PR to fix this. https://github.com/RamenDR/ramen/pull/350 2. PVCs created by StatefulSet Controller StatefulSet Pods will deploy and failover correctly, however, to relocate to the original cluster, a manual deletion of the PVCs of the previous run must be performed before issuing a failback request. This is a StatefulSet limitation https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#limitations. K8s v1.23 provides a solution to this problem.
Moved the bug to 4.13.