Cinder CSI device path can contain full cinder uuid instead of shorten one

[Isonami]

Is this a BUG REPORT or FEATURE REQUEST?:

/kind bug

What happened:
I use cinder with ceph rbd backend and on the host with mounted cinder volume I got device ids like this:

ls /dev/disk/by-id/
scsi-0QEMU_QEMU_HARDDISK_98f28d97-f961-45a9-87a8-fa7167d4fc0f
scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-0-0
scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-0-0-part2
scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-0-0-part4
scsi-0QEMU_QEMU_HARDDISK_a9218193-fead-41d0-a73e-944e1f006ea9
scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-0-0-part1
scsi-0QEMU_QEMU_HARDDISK_drive-scsi0-0-0-0-part3

and it doesn't match any of patterns which plugin looks for:

	candidateDeviceNodes := []string{
		// KVM
		fmt.Sprintf("virtio-%s", volumeID[:20]),
		// KVM virtio-scsi
		fmt.Sprintf("scsi-0QEMU_QEMU_HARDDISK_%s", volumeID[:20]),
		// ESXi
		fmt.Sprintf("wwn-0x%s", strings.Replace(volumeID, "-", "", -1)),
	}

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):
qemu instance disk configuration:

    <disk type='network' device='disk'>
      <driver name='qemu' type='raw' cache='writeback' discard='unmap'/>
      <auth username='cinder'>
        <secret type='ceph' uuid='ccc697e9-8261-4c22-a559-6647293cbe28'/>
      </auth>
      <source protocol='rbd' name='volumes/volume-a9218193-fead-41d0-a73e-944e1f006ea9'>
        <host name='10.1.1.10' port='6789'/>
        <host name='10.1.1.11' port='6789'/>
        <host name='10.1.1.12' port='6789'/>
      </source>
      <target dev='sdb' bus='scsi'/>
      <serial>a9218193-fead-41d0-a73e-944e1f006ea9</serial>
      <address type='drive' controller='0' bus='0' target='0' unit='1'/>
    </disk>
    <disk type='network' device='disk'>
      <driver name='qemu' type='raw' cache='writeback' discard='unmap'/>
      <auth username='cinder'>
        <secret type='ceph' uuid='ccc697e9-8261-4c22-a559-6647293cbe28'/>
      </auth>
      <source protocol='rbd' name='volumes/volume-98f28d97-f961-45a9-87a8-fa7167d4fc0f'>
        <host name='10.1.1.10' port='6789'/>
        <host name='10.1.1.11' port='6789'/>
        <host name='10.1.1.12' port='6789'/>
      </source>
      <target dev='sdc' bus='scsi'/>
      <serial>98f28d97-f961-45a9-87a8-fa7167d4fc0f</serial>
      <address type='drive' controller='0' bus='0' target='0' unit='2'/>
    </disk>

Anything else we need to know?:

Environment:

• openstack-cloud-controller-manager version:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

[chrigl]

@Isonami Interesting... Could you please pass some versions... coming to my mind

• OpenStack Nova
• OpenStack Cinder
• Libvirt
• Operating System of the worker
• Version of CSI or cinder volume provisioner

[Isonami]

• nova: 20.0.0
• cinder: 15.0.0
• libvirt: 5.4.0
• host os: Ubuntu 18.04 4.15.0-70-generic
• worker os: Fedora coreos 30 5.2.18-200.fc30.x86_64
• for CSI I used manifests from https://github.com/kubernetes/cloud-provider-openstack/tree/master/manifests/cinder-csi-plugin

I think worker os doesn't matter because I have same device ids on other vms in openstack

[chrigl]

Thanks @Isonami

Because I currently lack of an OpenStack with this behaviour... could you please test with this image chrigl/cinder-csi-plugin:ce99f3df in

• kubectl -n kube-system edit statefulset csi-cinder-controllerplugin
• kubectl -n kube-system edit ds csi-cinder-nodeplugin

... instead of docker.io/k8scloudprovider/cinder-csi-plugin:latest

[Isonami]

yes, it works