Glance-deactivate-image

This is the full specification for the blueprint https://blueprints.launchpad.net/glance/+spec/deactivate-image

Proposal

Introduce a new image status, 'deactivated'. When an image is in this state, access to the image's data (i.e., what's stored in /v2/images{image_id}/file) would be prohibited to any non-admin user.

Deny other operations?

This would allow other access to the image, e.g., it could be shared to more users (but those users wouldn't be able to use the image). We don't think this is a problem ... but we are open to other opinions!

API

The change in image status will be exposed through the Images v2 API. We propose the following calls:

deactivate image

POST /v2/images/{image_id}/actions/deactivate

Changes image status to 'deactivated'. If the current status of the image is not either "active" or "deactivated", the call will return an error. A successful call will return 204 (No Content).

There is no request body.

reactivate image

POST /v2/images/{image_id}/actions/reactivate

Changes image status to 'active'. If the current status of the image is not either "active" or "deactivated", the call will return an error. A successful call will return 204 (No Content).

There is no request body.

why not use PATCH?

While an image's status is exposed to the end user, the status transitions are managed by Glance. Image status is a reflection of the result of operations that Glance has been asked to perform relative to the image. Use of PATCH implies that 'status' is something that can be directly modified, like the image's name, for example. By using dedicated API calls to deactivate/reactivate an image, we respect the current use of the image status field.

FAQ

What does deactivating an image mean and what does it do?

Deactivating an image aims to essentially restrict any further instance builds from it. To achieve this, we propose to prohibit image downloads on a deactivated image. By also changing the status of the image, we can signal to image consumers who do caching that the image should no longer be used. For example, Nova checks the status of an image and only proceeds with the download-and-boot process if the image has status 'active'. Thus, if there's a cached copy of this image around, nova won't use it.

Consumers who aren't as pro-active in checking the image status will encounter an error response when they attempt to access the image data, and whatever they're trying to do will fail. As far as image caching goes, it's the responsibility of the maintainer of the local cache to follow normal cache protocol (i.e., make sure the image hasn't been deleted, etc.). The whole point of having 'active' image status is to signal that an image is still OK, we hope that most consumers act like nova and verify that an image has status 'active' rather than doing something not so smart.

Prohibiting image downloads will also prohibit operations such as image export and image cloning that may require image data.

Why prohibit image export and image cloning?

These two operations may result in further instance boots as one gets access to image data. Hence, we propose to prohibit these as well.

When can an image be deactivated?

An image can be deactivated only when it is already active. An image in any other status cannot be deactivated.

Is the image data still available when the image is deactivated?

Yes, the image data at all its locations will still be intact, just that no one would be able to download the image and hence, no one would be able to do any operations that require image data like, instance boot, image export and image cloning.

Who can deactivate an image?

There may be a use case for allowing a user to deactivate an image, but we see this primarily as an admin operation. If it's exposed to users, then they could reactivate an image that the glance admin has placed under investigation. Hence this operation should be restricted to admins.

Another possibility would be to protect the deactivate action by a policy where the default setting would be admin-only. Then it would be up to the deployer to decide who is allowed access to the call.

Change History

• Updated to include 'actions' in the URL in light of the "Functional API" discussion at the Juno design summit, https://etherpad.openstack.org/p/glance-adding-functional-operations-to-api