Description of problem (please be detailed as possible and provide log
snippests):

Version of all relevant components (if applicable):
OCP 4.17.0-0.nightly-2024-10-20-231827
ODF 4.17.0-126
ACM 2.12.0-DOWNSTREAM-2024-10-18-21-57-41
OpenShift Virtualization 4.17.1-19
Submariner 0.19 unreleased downstream image 846949
ceph version 18.2.1-229.el9cp (ef652b206f2487adfc86613646a4cac946f6b4e0) reef (stable)
OADP 1.4.1
OpenShift GitOps 1.14.0
VolSync 0.10.1

Does this issue impact your ability to continue to work with the product
(please explain in detail what is the user impact)?

Is there any workaround available to the best of your knowledge?

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

Can this issue reproducible?

Can this issue reproduce from the UI?

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

Steps to Reproduce:
1. On a ODF Regional DR setup, deploy a CNV workload for discovered app using data volume template from https://github.com/RamenDR/ocm-ramen-samples/tree/main/workloads/kubevirt/vm-dvt/odr-regional.
2. DR protect the workload using normal DRPolicy without flattening enabled.
3. After the 1st sync and backup has completed, create a clone of this parent PVC via OCP console.
4. Now deploy another workload consuming this cloned-PVC in such a way that the VM uses this cloned-PVC managed by a datavolume and the Pod writes IO to the same cloned-PVC.
5. Add the same label to this cloned-PVC as that on the parent PVC. The PVC gets DR protected on it's own but the VR CURRENTSTATE remains stuck as Unknown.
oc describe vr root-disk-clone-2
Name: root-disk-clone-2
Namespace: busybox-workloads-50
Labels: ramendr.openshift.io/owner-name=busybox50
ramendr.openshift.io/owner-namespace-name=openshift-dr-ops
Annotations: <none>
API Version: replication.storage.openshift.io/v1alpha1
Kind: VolumeReplication
Metadata:
Creation Timestamp: 2024-10-27T12:06:02Z
Finalizers:
replication.storage.openshift.io
Generation: 1
Resource Version: 9382190
UID: 8c402f4b-29d5-40b1-a5e5-984939d2f13c
Spec:
Auto Resync: false
Data Source:
API Group:
Kind: PersistentVolumeClaim
Name: root-disk-clone-2
Replication Handle:
Replication State: primary
Volume Replication Class: rbd-volumereplicationclass-1625360775
Status:
Conditions:
Last Transition Time: 2024-10-27T12:06:02Z
Message:
Observed Generation: 1
Reason: FailedToPromote
Status: False
Type: Completed
Last Transition Time: 2024-10-27T12:06:02Z
Message:
Observed Generation: 1
Reason: Error
Status: True
Type: Degraded
Last Transition Time: 2024-10-27T12:06:02Z
Message:
Observed Generation: 1
Reason: NotResyncing
Status: False
Type: Resyncing
Last Transition Time: 2024-10-27T12:06:02Z
Message:
Observed Generation: 1
Reason: PrerequisiteNotMet
Status: False
Type: Validated
Message: system is not in a state required for the operation's execution: failed to enable mirroring on image "ocs-storagecluster-cephblockpool/csi-vol-9fa1d5b8-70a0-4881-b428-8aed0779d256": parent image "ocs-storagecluster-cephblockpool/csi-vol-9fa1d5b8-70a0-4881-b428-8aed0779d256-temp" is not enabled for mirroring
Observed Generation: 1
State: Unknown
Events: <none>
This is probably because flattening is not enabled in the DRPolicy it is automatically being assigned to.
6. Now do the same operation by creating another clone and this time add an unique label on all the K8s resources to be backed to odrbucket, such as PVC, VM, DataVolume and Secret.
7. Now go to ACM console and try to DRprotect this cloned-PVC. On the Enroll discovered application page, select the cluster where workload is deployed and search for the namespace of the workload. UI doesn't list the namespace because the parent PVC is in the same namespace and is already DR protected. And enrolment case is not handled.

Now if we try to create a PVC clone in a different namespace via OCP console, the clone layout doesn't has the option to edit the namespace.

(Refer the attached screencast)

So if a PVC clone can not be created in a different namespace, there is no way we can DR protected the parent and child PVC both.

The same goes with a snapshot-restored PVC.

Actual results: [RDR] Parent and child PVC both can not be DR protected

Expected results: There should be a way to DR protect both the parent and child PVC

Additional info: