OADP-2074 [DataMover] Mirrored PVC snapcontent-*-pvc can have inconsistent storageclass from configmap options for volsync

See
https://issues.redhat.com/browse/OADP-1821?focusedId=22408832&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-22408832

This PVC sometimes have incorrect StorageClassName that did not match values set in DPA.

volume-snapshot-mover/controllers/pvc.go

Lines 62 to 75 in f3057bd

    
           pvcClone := &corev1.PersistentVolumeClaim{ 
        
           	ObjectMeta: metav1.ObjectMeta{ 
        
           		Name:      fmt.Sprintf("%s-pvc", vsb.Spec.VolumeSnapshotContent.Name), 
        
           		Namespace: vsb.Spec.ProtectedNamespace, 
        
           		Labels: map[string]string{ 
        
           			VSBLabel: vsb.Name, 
        
           		}, 
        
           	}, 
        
           } 
        
           op, err := controllerutil.CreateOrUpdate(r.Context, r.Client, pvcClone, func() error { 
        
           	return r.buildPVCClone(pvcClone, &vsClone) 
        
           })

For app with many PVCs, it is observed IMO that the first few snapcontent-*-pvc are of incorrect storageclassname, the newer later ones have expected storageclassnames.

NAME                                                   STATUS        VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                AGE
snapcontent-26cc8b3f-2815-4cb4-8a11-5bc105106e33-pvc   Terminating   pvc-e86f9b84-26ef-4625-8f66-11ec23ff21b9   1Gi        RWO            ocs-storagecluster-cephfs   63s
snapcontent-54364b00-32b9-41ea-a137-db21c323f61b-pvc   Bound         pvc-7a956252-4d9f-4586-8ac8-7ce5df008778   1Gi        RWO            ocs-storagecluster-cephfs   47s
snapcontent-43d5b420-f3e2-42fd-9d9f-d2a0e669e61c-pvc   Bound         pvc-f3414ff2-2cac-443f-877f-cc0d98f05f27   1Gi        RWX            new-sc                      46s
snapcontent-a904311c-d823-430e-aaeb-c58cae2b15aa-pvc   Bound         pvc-d2d08d90-42c8-4889-9965-707172415d27   1Gi        RWX            new-sc                      29s
snapcontent-4ed67f18-4fc3-47c9-8eaf-0241b92cc11a-pvc   Pending                                                                            new-sc                      3s

I don't think this is a bug.. the volumes all end up with correct storage class name AFAICT. 0/
https://hackmd.io/DlU9V4S4Q5yQP-TQYqGzDw

Volsync volumes sure. Transient "Mirrored PVC" volumes during backup created by volume-snapshot-mover do not always match the settings.

These are volumes in openshift-adp namespace

Said volumes are gone by the time backup is completed.. so you have to be watching during backup in progress

So either we don’t try to use SourceVolumeOptions at all in the mirror pvc.. or we fix it so that all Mirror PVCs have the same storageclass.

From the jira comments it seems we want to limit the effects of this volumeoptions to volsync. I can submit a PR for that.

Close via #237

	pvcClone := &corev1.PersistentVolumeClaim{
	ObjectMeta: metav1.ObjectMeta{
	Name: fmt.Sprintf("%s-pvc", vsb.Spec.VolumeSnapshotContent.Name),
	Namespace: vsb.Spec.ProtectedNamespace,
	Labels: map[string]string{
	VSBLabel: vsb.Name,
	},
	},
	}

	op, err := controllerutil.CreateOrUpdate(r.Context, r.Client, pvcClone, func() error {

	return r.buildPVCClone(pvcClone, &vsClone)
	})