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:
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.
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 "0x600605b00d6b e9e023586a26106 0047f". 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- 3600605b00d6be9 e023586a2610600 47f /dev/disk/ by-id/wwn- 0x600605b00d6be 9e023586a261060 047f /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.