restore-storage-configuration fails when a raid device is part of a bcache
Bug #1815091 reported by
Jason Hobbs
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MAAS |
Fix Released
|
Critical
|
Blake Rouse | ||
2.5 |
Fix Released
|
Critical
|
Blake Rouse |
Bug Description
This is with maas 2.5.0.
To reproduce, configure a raid device for a machine, and then make that raid device part of a bcache (in my test case, I made it the backing device).
Then use the 'restore-
ubuntu@dratini:~$ maas root machine restore-
Cannot delete block device because its part of a Bcache.
The expected behavior is that maas will restore the configuration regardless of its current state.
Related branches
~blake-rouse/maas:fix-1815091-2.5
- Blake Rouse (community): Approve
-
Diff: 111 lines (+66/-8)3 files modifiedsrc/maasserver/exceptions.py (+5/-0)
src/maasserver/models/node.py (+26/-8)
src/maasserver/models/tests/test_node.py (+35/-0)
~blake-rouse/maas:fix-1815091
Merged
into
maas:master
- MAAS Lander: Approve
- Andres Rodriguez (community): Approve
-
Diff: 111 lines (+66/-8)3 files modifiedsrc/maasserver/exceptions.py (+5/-0)
src/maasserver/models/node.py (+26/-8)
src/maasserver/models/tests/test_node.py (+35/-0)
tags: | added: cdo-qa |
Changed in maas: | |
status: | New → In Progress |
Changed in maas: | |
status: | In Progress → Fix Committed |
Changed in maas: | |
milestone: | 2.6.0 → 2.6.0alpha1 |
Changed in maas: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
The only workaround I'm aware of for this is to re-implement restore- storage- configuration outside of MAAS through API calls. That is a huge complex mess because we have to be very careful about the order in which storage devices are removed, and it is extremely slow, doubling the time of reconfiguring nodes in maas.