hook for storage: storage already attached - Juju using already mounted disk
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
High
|
Andrew Wilkins | ||
2.1 |
Fix Released
|
High
|
Andrew Wilkins | ||
2.2 |
Fix Released
|
High
|
Andrew Wilkins | ||
MAAS |
Fix Released
|
Critical
|
Blake Rouse |
Bug Description
When deploying Ceph OSD with MAAS provider:
juju deploy cs:xenial/ceph-osd --storage osd-journals=ssd,1 --storage osd-devices=sata,1 osd1
Juju hits bug 1656258, which is mitigated by a machine restart. Once node reboots, osd1 unit log shows:
2017-03-19 19:15:16 ERROR juju.worker.
2017-03-19 19:15:19 ERROR juju.worker.uniter agent.go:28 resolver loop error: preparing operation "run storage-attached (osd-journals/34) hook": inappropriate "storage-attached" hook for storage "osd-journals/34": storage already attached
juju list-storage shows:
osd1/0 osd-devices/33 pending
osd1/0 osd-journals/34 /dev/disk/
Machines has two SSD disks and multiple SATA disks, tagged as 'ssd' and 'rotary'. Storage pools were created as:
juju create-storage-pool sata maas tags=rotary
juju create-storage-pool ssd maas tags=ssd
On this machine sde is already used for the operating system.
Shouldn't juju skip disks that are already used?
Related branches
- Andres Rodriguez (community): Approve
-
Diff: 594 lines (+266/-135)4 files modifiedsrc/maasserver/api/tests/test_machines.py (+5/-9)
src/maasserver/node_constraint_filter_forms.py (+47/-49)
src/maasserver/testing/factory.py (+9/-2)
src/maasserver/tests/test_node_constraint_filter_forms.py (+205/-75)
Changed in juju: | |
milestone: | 2.2-rc1 → none |
tags: | added: uosci |
Changed in maas: | |
importance: | Undecided → Critical |
milestone: | none → 2.2.0rc2 |
status: | New → Confirmed |
tags: | added: stable-blocker |
tags: | added: cdo-qa-blocker |
Changed in maas: | |
assignee: | nobody → Blake Rouse (blake-rouse) |
status: | Confirmed → In Progress |
Changed in maas: | |
status: | In Progress → Fix Committed |
Changed in maas: | |
status: | Fix Committed → Fix Released |
Changed in juju: | |
milestone: | 2.3-beta1 → 2.3-beta2 |
Changed in juju: | |
milestone: | 2.3-beta2 → 2.3-beta1 |
Changed in juju: | |
status: | Fix Committed → Fix Released |
Ante, seems there's a couple of issues here:
- we shouldn't be selecting sde
- storage-attached is running after Juju thinks the storage is provisioned
When we acquire a MAAS node, we specify disk params (size & tags), and MAAS returns a device that matches them. We explicitly include a root disk in there, but don't report it in the Juju model. So either MAAS is giving us back the root disk, or we're doing the mapping between MAAS-reported disks and what Juju asked for incorrectly. I can't immediately see any issues with the code on our end. Are you able to reproduce this? Can you provide the HTTP requests/responses from Juju to MAAS?
As for storage-attached after provisioning... I've not seen that before. If you have an environment where you can repro and I can poke around, that would be most helpful.