Comment 17 for bug 1778033

Revision history for this message
Ian Booth (wallyworld) wrote :

When Juju provisions a machine with storage, depending on the provider, it generally gets back from the start api call information from the provider about each volume that has been provisioned, including:
- wwn
- hardware id

plus info about how that volume is/will be attached to the machine, including:
- bus address
- device link
- device name

The content of the volumes and volumeattachments collections shows that MAAS is providing Juju with the wwn of each volume and no information about the attachment of that volume.

For the uniter to run the storage attached hook, it needs to know that the storage attachment has been completed, and this is done by polling the block devices using lsblk. The info from lsblk is recorded and matched with the volume/attachment info obtained from the maas apis when the machine was provisioned.

The block device info from lsblk that Juju can parse includes device name, size, label uuid, type etc. So just the basic info to record a block device exists.

So we're down to matching my WWN. There is a volume info record for "osd-devices/40" which has a WWN of "0x600605b00d6be9e023586a261060047f". And in lsblk output there is a record of that block device being present:

2018-11-20 11:08:05 INFO juju.worker.diskmanager diskmanager.go:67 block devices changed: [{sda [/dev/disk/by-id/scsi-3600605b00d6be9e023586a261060047f /dev/disk/by-id/wwn-0x600605b00d6be9e023586a261060047f /dev/disk/by-path/pci-0000:0b:00.0-scsi-0:2:0:0]...

Juju can't reliably parse the WWN from this so it then runs for each device "udevadm":

udevadm info -q property --name <deviceName>

It looks for "ID_WWN=xxxxx" in the output.

So what we need to look further is the udevadm output for say "osd-devices/40" and maybe a few others, plus the content of the "blockdevices" collection. We need to find out why Juju cannot match the block devices with the volume/attachment info from MAAS.

Note, udevadm is used to get the bus address of the device. The bus address is expected to be in the format:

.../X.X.X.X/block/<devicename>

where as for this deployment the udevadm output produces:

.../1:2:0:0/block/sdo/sdo3

The extra "sdo" bit means that Juju cannot parse a bus address. That might be an issue but it's not here because the volume attachment data from MAAS doesn't contain a bus address we can match against anyway.