An Operation to Deactivate an Image in Glance

Registered by Hemanth Makkapati

The goal of this blueprint is to introduce a mechanism to deactivate an image.

An important usecase is as follows:
A "bad" image in a cloud, especially now with image sharing available, may cause a greater damage as more and more instances can be spun off of it. A "bad" image may get into a cloud in the following ways (there maybe other ways too) :
 - It was crafted outside the cloud and was imported into the cloud
 - It was crafted inside the cloud after booting off of a known good image

Once such an image is found inside the cloud, there is need for an operation to 'deactivate' it until further investigation can be performed. The investigation itself is outside the scope of this blueprint. Once a thourough investigation is performed, a deactivated image can be activated again or deleted depending on the investigation findings.

The proposed mechanism is to introduce a new image status, 'deactivated'. When an image is in this state, access to its data would be prohibited for non-admin users.

(Note: there was an earlier spec on the wiki:

Blueprint information

Nikhil Komawar
Hemanth Makkapati
Eddie Sheffield
Series goal:
Accepted for kilo
Milestone target:
milestone icon 2015.1.0
Started by
Nikhil Komawar
Completed by
Nikhil Komawar

Related branches



May I know what kind of access will be block for the non-admin users you planned? Thanks.

you mean in terms of access to this API call or what happens after an image is deactivated? - Hemanth
later one. Block what operations for a deactivated image? --zhiyan
Once an image is deactivated, non-admin users should not be able to fetch image data. Any other operation that depends on getting imade data would eventually fail.

Originally proposed for icehouse-3.
I think we need more information, and I need to think more about this before we approve the definition. I think the direction, in terms of the problem we want to solve, is completely clear and makes sense. However, I'm still wondering if this is something we should be doing with properties and more on the nova/cinder side? or if we should actually be restricting download. So I have a starting list of questions
1) what is the UX like for consumers of that image when they boot in nova, or provision a volume, or rebuild a server that was built with that image originally?
2) should we be structuring this as policy/permissions rather than image attributes?
3) is this generalizeable to artifacts (just a thought experiment) or is it definitely image specific, and why

Based on the number of open questions here and the lateness, I think we probably cannot plan to land this in icehouse-3.

markwash more-info 2014-02-14

Marking abandoned for now, if someone wants to start working on it, please assign yourself.
untagging markwash abandoned 2014-03-07

chatted with Hemanth and he is resuming work on answering the questions above.
markwash more-info 2014-03-07

1) I spoke to Andrew Laski and Alex Meade about this.
On a download failure Nova would retry the download multiple times on a host before it schedules the build to another host and try again. This can be avoided by returning a 4xx error, which nova treats as non-retryable errors.
On the other side, it seems Cinder will let the volume go to error if it can't fetch the data. Apparently, Cinder just logs the error and the user is not intimated about it. I'm researching more into this.

2) Here, I am assuming you are exploring the possibility of prohibiting download or whatever is the function of 'deactiving' an image without introducing a new image attribute, in this case a new status, 'decativated'. I see two different actions/steps here i) identification of a bad image ii) enforcing action on a bad image.

i) Identification of a bad image:
    This is where the identification of a bad image happens. This identification can happen both automatically (at least in theory) and manually. At least as of now, identification of a bad image is not something we can do automatically. So, most likely we would rely on human intervention (probably by monitoriong/ops personnel) to identify a bad image. Hence, we need a mechanism for them to identify/flag an image as bad. To do this I believe a new status would serve really well.

ii) Enforcing action on a bad image:
    Once an image is identified as bad, we need to prohibit the download or whatever action we deem is appropriate. This maybe enforced using roles/permissions. It is very likely that we would prohibit download for all users excepting admins.

3) I think this could be generalizable to artifacts as well. All we do here is prohibit the use of a 'bad' image and this should directly translate to prohibiting the use of a 'bad' artifact, if there is a need for such a feature. However, depending on the use case, the 'actions' that are prohibited on a bad artifact may differ from images. Also, it is important to consider the definition of 'bad' for artifacts. However, this is subject to whether or not we leave identification of a 'bad' image/artifact itself out of Glance.


we need some more discussion, maybe in next glance meeting, about what the API for this would look like (i.e., use PATCH or use dedicated API calls as described in the full spec).
rosmaita more-info 2014-03-28

The spec has been updated based on the discussion in glance meeting and glance channel. We decided to go ahead with a functional interface as opposed to using PATCH. We shall be implementing this as a POST to '/images/UUID/deactivate' and '/images/UUID/reactivate' to deactivate and reactivate an image.

Gerrit topic:,topic:bp/deactivate-image,n,z

Addressed by:
    Add ability to deactivate an image


Work Items

This blueprint contains Public information 
Everyone can see this information.