Available volume status with attachments
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
New
|
High
|
Gorka Eguileor |
Bug Description
With the new attachment API a volume can end up with a volume showing an "available" status and "detached" attach_status but still have attachments.
These attachments will be in an error status, "error_detaching" or "error_attaching", and the volume may still be exported and even mapped to a host.
This presents 2 issues:
- Inconsistent view: Volume available but has attachments.
- Deleting the available volume may turn the volume into error state and not be easy to figure out why (deleting the attachments first would provably solve the issue).
The error deleting the volume depends on the driver implementation, and would fail if:
- The volume is still mapped and the remove_export fails when the volume is still mapped.
- The volume is still mapped, the remove_export does nothing, and the backend doesn't allow deleting mapped volumes.
We either need to take into account attachments in error state when deciding the status and attach_status of volumes, or do the proper deletion of error attachments when an error request is received.
Changed in cinder: | |
importance: | Undecided → High |
tags: | added: api |
tags: | added: attachment volume |