Adding status property to image location
Adding status for each image backend storage location to optimize Glance deployment mode. Operator can deploy glance more easy and keep high performance, and using a centralized scrubber service but deploy it on each glance-api node.
1. Add a status field to image location DB entry. Three possible states are 'active', 'pending_delete', and 'deleted'.
2. Keep location status be internal, only display/export locations by API if they are 'active'.
3. The public API doesn't need to change.
4. Image location status migration initially:
image-status => location-status
-------
queued => <None>
saving => <None>
active => active
pending_delete => pending_delete
killed or deleted => deleted
5. Image location status transition DAG diagram:
image upload data or new location(s) added ==>
'active' status ==> image deleted by api controller ==>
if CONF.delayed_delete disable ==> delete image ==> 'deleted' status (end)
Blueprint information
- Status:
- Complete
- Approver:
- Mark Washenberger
- Priority:
- Medium
- Drafter:
- Zhi Yan Liu
- Direction:
- Approved
- Assignee:
- Zhi Yan Liu
- Definition:
- Approved
- Series goal:
- Proposed for juno
- Implementation:
-
Implemented
- Milestone target:
-
next
- Started by
- Zhi Yan Liu
- Completed by
- Zhi Yan Liu
Related branches
Related bugs
Sprints
Whiteboard
Addressed by: https:/
Adding status field to image location
Question here:
We probable need a clearer vision of what all we want on locations. And need some sort of proposal for what we want the locations attributes to look like. I'm concerned if we grow incrementally without something like the final picture in our minds, we'll end up repeating past mistakes, such as complicated state diagrams for image.
<jbresnah>
I think this is good and needed work. Having many locations without an associated state is probably not a good thing.
I have a couple of questions:
1) what will become of the legacy status field associated with the image? Will the reflect the most available location? Will it be deprecated?
I consider image status should be reserved since it's a status form image entry/metatdata but not a particular location within it. For example image status can be 'pending' which means image has no location yet. -- zhiyan
2) I would really like to see a state diagram DAG of the transition for each location to help explain how they will move when various events occur.
Agreed, I'd like discuss this with you. -- zhiyan
</jbresnah>
I'd like to see the quota code being more granular as part of this blueprint. We're currently counting image's space based on the image status and not the image location status which is what actually allocates the space.
-- flaper87
Addressed by: https:/
Adding encryption support for image multiple locations
Addressed by: https:/
Using Database to support image pending deleting
Addressed by: https:/
Adding status field to image location
Addressed by: https:/
Adding status field to image location
Addressed by: https:/
Adding status field to image location
Work Items
Dependency tree
* Blueprints in grey have been implemented.
