volume delete failure message could be better
Bug #1826220 reported by
Eric Harney
This bug affects 2 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Cinder |
In Progress
|
Low
|
ye | ||
Bug Description
"Invalid volume: Volume status must be available or error or error_restoring or error_extending or error_managing and must not be migrating, attached, belong to a group, have snapshots or be disassociated from snapshots after volume transfer."
This is a lot of assorted, mostly irrelevant, pieces of information to throw back to a user in an error message.
We should dynamically construct this message -- if the volume isn't in "error_managing", don't mention that state, if it's not in a group, don't say anything about groups, etc.
| tags: | added: low-hanging-fruit |
Revision history for this message
| Brin Zhang (zhangbailin) wrote | #2 |
Revision history for this message
| ye (dakele) wrote | #3 |
| Changed in cinder: | |
| assignee: | nobody → ye (dakele) |
Revision history for this message
| OpenStack Infra (hudson-openstack) wrote Fix proposed to cinder (stable/rocky) | #4 |
Revision history for this message
| OpenStack Infra (hudson-openstack) wrote Change abandoned on cinder (stable/rocky) | #5 |
Revision history for this message
| OpenStack Infra (hudson-openstack) wrote Fix proposed to cinder (master) | #6 |
| Changed in cinder: | |
| status: | New → In Progress |
Revision history for this message
| OpenStack Infra (hudson-openstack) wrote Change abandoned on cinder (master) | #7 |
To post a comment you must log in.
Note: implementing this is a lot harder than it sounds at first.
A message like this results from a single database conditional_update which checks all of the listed conditions. This conditional_update does not currently provide back enough info to see which of the conditions failed, hence the message listing all possible conditions.
I considered trying to poll the status field etc., after the conditional_update failed to find the reason, but this only works if the object hasn't been updated in the db, which I don't think we can guarantee in general. (Maybe we can if we check that the object's updated_at time hasn't changed.)