DataUploader Pod terminates immediately if PV is not yet provisioned

[realjump]

Hello everyone,

after the version upgrade to Velero 1.14.0 we noticed that there is a problem with the DataUploader Pods.

In our previous version (1.12.2), the DataUploader Pod always waited in Pending status until its corresponding PVC was provisioned by the CSI. Since version 1.14.0, the pod terminates immediately because the provisioning of the PVC takes some time.

The DataUpload-CR then immediately gets the status 'canceled' with the message "found a dataupload velero/backup-name-lxgv6 with expose error: Pod is unschedulable: 0/13 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/13 nodes are available: 13 Preemption is not helpful for scheduling... mark it as cancel"

Has anyone noticed anything similar or have any idea if this can/must be configured in some way in the new version?

### Velero Events 1.14.0:

• Normal SnapshotReady - volumesnapshot/backup-name-lxgv6 - snapshot velero/backup-name-lxgv6 is ready to use.
• Normal Provisioning - persistentvolumeclaim/backup-name-lxgv6- External provisioner is provisioning volume for claim velero/backup-name-lxgv6
• Normal ExternalProvisioning - persistentvolumeclaim/backup-name-lxgv6 - waiting for a volume to be created, either by external provisioner spectrumscale.csi.ibm.com or manually created by system administrator
• Warning FailedScheduling - pod/backup-name-lxgv6 - 0/13 nodes are available: pod has unbound immediate PersistentVolumeClaims. preemption: 0/13 nodes are available: 13 Preemption is not helpful for scheduling.
• Normal ExternalProvisioning - persistentvolumeclaim/backup-name-lxgv6 - waiting for a volume to be created, either by external provisioner spectrumscale.csi.ibm.com or manually created by system administrator
• Warning FailedScheduling - pod/backup-name-lxgv6 - **skip schedule deleting pod: velero/backup-name-lxgv6**
• Normal ExternalProvisioning - persistentvolumeclaim/backup-name-lxgv6 - waiting for a volume to be created, either by external provisioner spectrumscale.csi.ibm.com or manually created by system administrator
• Warning SnapshotDeletePending - volumesnapshot/backup-name-lxgv6 - Snapshot is being used to restore a PVC

### Velero Events 1.12.2:

• Normal Provisioning - persistentvolumeclaim/backup-name-jztt6 - External provisioner is provisioning volume for claim "velero/backup-name-jztt6"
• Normal ExternalProvisioning - persistentvolumeclaim/backup-name-jztt6 - waiting for a volume to be created, either by external provisioner "spectrumscale.csi.ibm.com" or manually created by system administrator
• Warning FailedScheduling - pod/backup-name-jztt6 - 0/79 nodes are available: 79 pod has unbound immediate PersistentVolumeClaims. preemption: 0/79 nodes are available: 79 Preemption is not helpful for scheduling.
• Warning ProvisioningFailed - persistentvolumeclaim/backup-name-jztt6 - failed to provision volume with StorageClass "sc-name": error getting handle for DataSource Type VolumeSnapshot by Name backup-name-jztt6: snapshot backup-name-jztt6 is not Ready
• Warning FailedScheduling - pod/backup-name-jztt6 - 0/79 nodes are available: 79 pod has unbound immediate PersistentVolumeClaims. preemption: 0/79 nodes are available: 79 Preemption is not helpful for scheduling.
• Normal SnapshotCreated - volumesnapshot/backup-name-jztt6 - Snapshot velero/backup-name-jztt6 was successfully created by the CSI driver.
• Normal SnapshotReady - volumesnapshot/backup-name-jztt6 - Snapshot velero/backup-name-jztt6 is ready to use.
• Normal ProvisioningSucceeded - persistentvolumeclaim/backup-name-jztt6 - Successfully provisioned volume pvc-xxx-xxx-xxx-xxx-xxx
• Normal Scheduled - pod/backup-name-jztt6 - Successfully assigned velero/backup-name-jztt6 to node-name
• Normal SuccessfulAttachVolume - pod/backup-name-jztt6 - AttachVolume.Attach succeeded for volume "pvc-xxx-xxx-xxx-xxx-xxx"

Best regards

[Lyndon-Li]

This is a known issue for 1.14 #7898. You need to wait 1.14.1 for the fix and for now, you can use 1.13.x

[realjump]

Thanks for the quick reply - I'm reassured that this is already known.