PVC clone does not restore source volume data from VolumeSnapshot #3

Description

Environment cloning successfully creates the destination environment and provisions a new PVC/PV, but the destination PVC does not contain the data from the source PVC.

This was reproduced while cloning a Vaultwarden environment:

• Source environment: 3386
• First clone: 3387
• Second clone: 3388

The same behavior was observed in both clone attempts.

Steps to reproduce

1. Deploy Vaultwarden with a PVC containing existing data in environment 3386.
2. Clone environment 3386 to a new environment.
3. Verify that the source VolumeSnapshot is created and reaches readyToUse: true.
4. Verify that the destination environment and PVC are created successfully.
5. Mount the destination PVC to the cloned Vaultwarden instance.
6. Check the /data directory and Vaultwarden data.

Expected behavior

The destination PVC should be provisioned from the source VolumeSnapshot.

The expected flow is:

Source PVC
↓
VolumeSnapshot
↓
VolumeSnapshotContent
↓
snapshotHandle
↓
Destination PVC with VolumeSnapshot as dataSource
↓
Cinder CSI creates a new volume from the snapshot
↓
Destination PV/PVC
↓
Source data available in /data

The destination should receive a new PVC/PV/Cinder volume identity while preserving the data from the source PVC.

Actual behavior

The source VolumeSnapshot is successfully created and reaches:

status:
readyToUse: true

with a valid snapshot handle.

However, the destination PVC does not contain a dataSource or dataSourceRef referencing a VolumeSnapshot.

For environment 3388, there is also no destination VolumeSnapshot in the destination namespace.

The destination PVC is instead provisioned as a normal PVC by:

cinder.csi.openstack.org

and receives a new Cinder volume.

As a result, the cloned Vaultwarden /data directory is empty instead of containing the source environment's data.

Environment

• OS: Ubuntu
• Kubernetes version: 1.32.13-4 (OVH Managed Kubernetes)
• Storage provisioner: cinder.csi.openstack.org
• StorageClass: csi-cinder-high-speed-gen2
• Volume type: high-speed-gen2
• Volume mode: Filesystem
• Access mode: ReadWriteOnce

Additional context

Source PVC:

vaultwarden-data-zerone-stable-metadata-3386-vaultwarden-0

Source Cinder volume handle:

25208223-d24a-4ac0-a04b-7a8b3f19341c

Source snapshot handle:

6da7f3af-8c7c-413a-b413-79f0b6a9b9ae

Destination PVC for environment 3388:

vaultwarden-data-zerone-stable-metadata-3388-vaultwarden-0

Destination Cinder volume handle:

52ec0e06-945a-4de1-b8b4-ec7eb974a22e

The destination PVC events show successful normal provisioning:

• ExternalProvisioning
• Provisioning
• ProvisioningSucceeded

However, there is no evidence in the destination PVC that the volume was provisioned from the source snapshot.

Additionally, the cloned environment storage metadata still contains source environment 3386 references:

environment_id: 3388
name: ...3386...
volume_name: ...3386...

Investigation points

The clone implementation should be investigated from the point where the snapshot handle is obtained through destination PVC creation, specifically:

1. How the destination VolumeSnapshot is created or referenced.
2. Whether the destination PVC is created with spec.dataSource or dataSourceRef.
3. Whether the Cinder CSI CreateVolume request contains the snapshot as its VolumeContentSource.
4. Whether source storage metadata is incorrectly reused for the destination environment.
5. Whether the clone operation verifies that snapshot-based volume restoration completed before reporting the environment as Running.