Comment 4 for bug 1790728

Re-opening this bug as we're seeing a mismatch between the block device path presented by Juju and the actual block device associated with a cinder volume.

The 'device' attribute of the attachment that is created for a volume in OpenStack is foobar; there is no way that Nova/Libvirt/Qemu and enforce this in the guest (think windows guests) and the block device path will be allocated when the udev events fire for the block device presentation.

That said Nova does make an effort to inject some metadata into the block device name via libvirt/qemu (this only works for virtio devices):

$ sudo udevadm info --query=all --name=/dev/vdc
P: /devices/pci0000:00/0000:00:06.0/virtio3/block/vdc
N: vdc
S: disk/by-id/virtio-abf836a3-0dcf-48d9-9
S: disk/by-path/pci-0000:00:06.0
S: disk/by-path/virtio-pci-0000:00:06.0
S: disk/by-uuid/305ec52e-4e50-4a51-ac35-85dd0a84a232
E: DEVLINKS=/dev/disk/by-uuid/305ec52e-4e50-4a51-ac35-85dd0a84a232 /dev/disk/by-path/pci-0000:00:06.0 /dev/disk/by-path/virtio-pci-0000:00:06.0 /dev/disk/by-id/virtio-abf836a3-0dcf-48d9-9
E: DEVNAME=/dev/vdc
E: DEVPATH=/devices/pci0000:00/0000:00:06.0/virtio3/block/vdc
E: DEVTYPE=disk
E: ID_FS_TYPE=xfs
E: ID_FS_USAGE=filesystem
E: ID_FS_UUID=305ec52e-4e50-4a51-ac35-85dd0a84a232
E: ID_FS_UUID_ENC=305ec52e-4e50-4a51-ac35-85dd0a84a232
E: ID_PATH=pci-0000:00:06.0
E: ID_PATH_TAG=pci-0000_00_06_0
E: ID_SERIAL=abf836a3-0dcf-48d9-9
E: MAJOR=252
E: MINOR=32
E: SUBSYSTEM=block
E: TAGS=:systemd:
E: USEC_INITIALIZED=2059336

$ openstack volume list

| abf836a3-0dcf-48d9-9cb0-ff679665ba8b | tools | in-use | 200 | Attached to jamespage-bastion on /dev/vdc |

The ID_SERIAL of the volume matches the start of the UUID allocated for the volume by cinder.

We think this is the only reliable way to map a cinder volume to the actual block device presented within an OpenStack Cloud.