[CSI]DeleteVolumeRequest：A parameter must be added to transfer the PV name of the volume to be deleted

[redriverhong]

Describe the issue

Is your feature request related to a problem?/Why is this needed
Currently, the DeleteVolumeRequest is only one parameter VolumeId, which is used to transfer the volume to be deleted. However, this requirement cannot be met in the scenario where PV volumes are preset.

for example：
apiVersion: v1
kind: PersistentVolume
metadata:
annotations:
pv.kubernetes.io/provisioned-by: com.localcsi
pv.kubernetes.io/create-by: manual // Identifier Manually Preset
name: pv-test-0
spec:
capacity:
storage: 256Mi
accessModes:

ReadWriteOnce
claimRef:
apiVersion: v1
kind: PersistentVolumeClaim
name: data-test-0
namespace: default
persistentVolumeReclaimPolicy: Retain
volumeMode: Filesystem
storageClassName: local
csi:
driver: com.localcsi
fsType: ext4
volumeHandle: caasvg_lv // volumeId
nodeAffinity:
required:
nodeSelectorTerms:
matchExpressions:
key: kubernetes.io/hostname
operator: In
values:
master1
apiVersion: v1
kind: PersistentVolume
metadata:
annotations:
pv.kubernetes.io/provisioned-by: com.localcsi
pv.kubernetes.io/create-by: manual // Identifier Manually Preset
name: pv-test-1
spec:
capacity:
storage: 256Mi
accessModes:

ReadWriteOnce
claimRef:
apiVersion: v1
kind: PersistentVolumeClaim
name: data-test-1
namespace: default
persistentVolumeReclaimPolicy: Retain
volumeMode: Filesystem
storageClassName: local
csi:
driver: com.localcsi
fsType: ext4
volumeHandle: caasvg_lv // volumeId
nodeAffinity:
required:
nodeSelectorTerms:
matchExpressions:
key: kubernetes.io/hostname
operator: In
values:
master2
For the preceding two PVs, if I want to delete the first PV, only one volumeId is sent to me when I invoke the volume deletion interface. but the volumeId of the two PVs is the same and the volume of the node to be deleted cannot be identified.

So raised this issue to add a parameter pvName in DeleteVolumeRequest.

Describe the solution you'd like in detail

[Kubernetes Prow Robot]

@redriverhong: The label(s) sig/<storage> cannot be applied, because the repository doesn't have them.

In response to this:

/sig

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.

[redriverhong]

/sig storage

[Bob Killen]

@redriverhong this repo is more like a meta repo that is used to manage the community, your issue won't really be seen here by those that can respond to it. =/ I'd suggest reaching out on the sig-storage mailing list or bringing it up in slack.

[Kubernetes Triage Robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[Kubernetes Triage Robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[Kubernetes Triage Robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[Kubernetes Prow Robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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-sigs/prow repository.