Adding status property to image location

Registered by Zhi Yan Liu

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)
                                             |---- enabled ==> schedule delayed delete ==> 'pending_delete' status
                                                                                 ==> Scrubber delete image ==> 'deleted' status (end)

Blueprint information

Mark Washenberger
Zhi Yan Liu
Zhi Yan Liu
Series goal:
Proposed for juno
Milestone target:
milestone icon next
Started by
Zhi Yan Liu
Completed by
Zhi Yan Liu

Related branches



Addressed by:
    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.


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


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:
    Adding encryption support for image multiple locations

Addressed by:
    Using Database to support image pending deleting

Addressed by:
    Adding status field to image location

Addressed by:
    Adding status field to image location

Addressed by:
    Adding status field to image location


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.