[Azure] Storage may be added with wrong device path and breaks charm
Bug #1936752 reported by
Pedro Guimarães
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
High
|
Ian Booth |
Bug Description
Juju 2.9.8
Generally, storage path that is passed to charms follows the pattern:
/dev/disk/
As described on: https:/
However, some times the path that comes up is:
# storage-get -s data/0
kind: block
location: /dev/disk/
Which is non-existent.
Path of available volumes and their symlinks on the same unit: https:/
Changed in juju: | |
milestone: | none → 2.9.10 |
assignee: | nobody → Ian Booth (wallyworld) |
importance: | Undecided → High |
status: | New → In Progress |
Changed in juju: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
I tried a simple experiment to reproduce this. I had a simple demo charm with storage
storage:
data:
type: block
multiple:
range: 1+
In the data-storage- attached and data-storage- detaching hook I logged the output of "storage-get" to a file.
After deploying the charm, "juju storage --format yaml" and the storage location made available to the attached hook via storage-get both had "/dev/disk/ azure/scsi1/ lun1".
Then I "juju detach-storage data/1" and the detaching hook was also supplied the expected location "/dev/disk/ azure/scsi1/ lun1".
The bug says that "sometimes" the wrong path is used. How often does this happen? In such cases, what does "juju storage --format yaml" show before the storage is detached? Is it possible to get the storage, volume and volume attachment collection data from the "juju dump-db" output?
Is there a particular charm that the issues occurs for regularly?