Clone from raw block pvc failed

[cumirror]

1. Create a pvc

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: p1
spec:
  volumeMode: Block
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-hostpath-sc

2. clone from pvc

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: p1-clone
spec:
  storageClassName: csi-hostpath-sc
  dataSource:
    name: p1
    kind: PersistentVolumeClaim
    apiGroup: ""
  accessModes:
    - ReadWriteOnce
  volumeMode: Block
  resources:
    requests:
      storage: 1Gi

The cloned PVC remains in the Pending state:

# kubectl get pvc -o wide
NAME       STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS          AGE    VOLUMEMODE
p1         Bound     pvc-97b8c8dc-596b-4c32-b94d-84fe859ffa42   1Gi        RWO            csi-hostpath-sc       4m4s   Block
p1-clone   Pending                                                                        csi-hostpath-sc       3m8s   Block
# kubectl describe pvc p1-clone
Name:          p1-clone
Namespace:     default
StorageClass:  csi-hostpath-sc
Status:        Pending
Volume:
Labels:        <none>
Annotations:   volume.beta.kubernetes.io/storage-provisioner: hostpath.csi.k8s.io
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode:    Block
DataSource:
  APIGroup:
  Kind:      PersistentVolumeClaim
  Name:      p1
Mounted By:  <none>
Events:
  Type     Reason                Age                  From                                                                                 Message
  ----     ------                ----                 ----                                                                                 -------
  Warning  ProvisioningFailed    4m16s                hostpath.csi.k8s.io_csi-hostpath-provisioner-0_b54909de-7793-4038-a581-f7206c6ff104  failed to provision volume with StorageClass "csi-hostpath-sc": rpc error: code = DeadlineExceeded desc = context deadline exceeded
  Normal   ExternalProvisioning  4s (x19 over 4m26s)  persistentvolume-controller                                                          waiting for a volume to be created, either by external provisioner "hostpath.csi.k8s.io" or manually created by system administrator
  Normal   Provisioning          3s (x9 over 4m26s)   hostpath.csi.k8s.io_csi-hostpath-provisioner-0_b54909de-7793-4038-a581-f7206c6ff104  External provisioner is provisioning volume for claim "default/p1-clone"
  Warning  ProvisioningFailed    3s (x8 over 4m16s)   hostpath.csi.k8s.io_csi-hostpath-provisioner-0_b54909de-7793-4038-a581-f7206c6ff104  failed to provision volume with StorageClass "csi-hostpath-sc": rpc error: code = AlreadyExists desc = existing volume source volume id not matching

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[cumirror]

csi-hostpath-provisioner log:

CreateVolume failed, supports topology = true, node selected false => may reschedule = false => state = Background: rpc error: code = DeadlineExceeded desc = context deadline exceeded

Timeout for waiting for creation or deletion of a volume (default 10s), after increased timeout, pvc clone success.

[pohly]

/reopen

So you found the reason, good. But we shouldn't we fix this in the repo?

Also, did CreateVolume always fail? The driver should continue with preparing the volume and eventually the CreateVolume call should succeed. In other words, a higher timeout helps to avoid intermittent errors, but it shouldn't be necessary.

[k8s-ci-robot]

@pohly: Reopened this issue.

In response to this:

/reopen

So you found the reason, good. But we shouldn't we fix this in the repo?

Also, did CreateVolume always fail? The driver should continue with preparing the volume and eventually the CreateVolume call should succeed. In other words, a higher timeout helps to avoid intermittent errors, but it shouldn't be necessary.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[pohly]

Which version of the csi-driver-host-path were you using?

Bug fixes around concurrent calls went into 1.5 (#220) and 1.6 (#270).

In particular, #220 seems to address this issue.

/close

[k8s-ci-robot]

@pohly: Closing this issue.

In response to this:

Which version of the csi-driver-host-path were you using?

Bug fixes around concurrent calls went into 1.5 (#220) and 1.6 (#270).

In particular, #220 seems to address this issue.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[905049079]

csi-hostpath-provisioner 日志：

CreateVolume failed, supports topology = true, node selected false => may reschedule = false => state = Background: rpc error: code = DeadlineExceeded desc = context deadline exceeded

等待创建或者删除卷的超时时间（默认10秒），增加超时时间后，pvc克隆成功。

May I ask how to modify the timeout period？