Can not use an id of a deleted image

Asked by Wallace Cardoso


I'm making some tests here, and I'm using a virtual machine as the controller and it is up through devstack. But using the API spec (Image API) and using requests library from Python 3, getting a token (authenticated and scoped in the admin project), I can not use an id that I have used before of a deleted image. Is that a correct behavior?

My steps:
- Use devstack to create a multilab openstack (1 controller and 2 computes)
- create an image using POST with the basics (disk_format, container_format)
- delete the image using the id through DELETE http method
- try to create another image using the same id

Result: conflict

Ps.: horizon does not show the image and the REST api does not return any image corresponding to that id, thus it is deleted

OpenStack Branch: stable/rocky

Question information

English Edit question
Glance Edit question
No assignee Edit question
Solved by:
Wallace Cardoso
Last query:
Last reply:
Revision history for this message
Brian Rosmaita (brian-rosmaita) said :

This is correct behavior. The reason you can't reuse a deleted image ID is that it would allow the following bad behavior:
1. create a good image people would want to use
2. share the image, either using image sharing or by giving it community visibility
3. get people interested in using the image
4. delete the image
5. using that same ID, upload a new image that has some kind of bad stuff in it (a backdoor, tracking software, etc.)

This is described by

Also, here's some information about OSSN-0075 and the glance database management tool:

Revision history for this message
Wallace Cardoso (wallacec) said :


But if I want to use an automatic script, how to know which are these ids? This is my intention. I check if the image exists using the id provided by the user and if the show images operation does not reveal that any image exists for the id then this means I can create the image for the user. If I understand, the only way so is to try creating the image and in case of a conflict error, I retry the image creation. However, the coding of this sounds to me not so pretty. There should exist a way of knowing which ids are allowed to be used to avoid depending on exceptions in the logical flow.

Have you a suggestion?

Revision history for this message
Brian Rosmaita (brian-rosmaita) said :

I'd suggest you reconsider your workflow. Why does a user need to specify a UUID in the first place? Just let the system assign the UUID, and encourage your users to supply image properties so that they can identify the image. This will give you an overall better user experience -- is it easier to recognize 2d4ec3e1-d8cb-4aa2-ab6c-5c8248de3d96 as the image I uploaded yesterday, or an image named "CentOS 7 LAMP stack 2019-10-10"?

Being able to specify a UUID on image creation was introduced for a special case, namely, that of public clouds divided into isolate "regions" where it would simplify some things to allow a particular public "base" image to have the same UUID in every region. But it's a better practice to annotate an image record with custom metadata that will allow you to write a script to search for the particular image you want.

As far as prettiness goes, you need to be prepared to handle a 4xx response when you try image creation. For example, a container_format or disk_format you want to use may not be supported in that cloud.

One other thing: only an image-list response for an administrator will contain all the image IDs currently in use. If you're a regular user, you only see the image IDs of images that you own. So if Fred owns 2d4ec3e1-d8cb-4aa2-bb6c-5c8248de3d96, and Barney makes the call GET /v2/images/2d4ec3e1-d8cb-4aa2-bb6c-5c8248de3d96, Barney will get a 404 (Not Found). Barney doesn't get a 403 (Forbidden) because we don't want any information leakage that resource 2d4ec3e1-d8cb-4aa2-bb6c-5c8248de3d96 exists--it's not Barney's business because it's not his resource.

I'm mentioning this 404 instead of 403 design decision, which has always been part of Glance, because it implies that returning a list of all in-use IDs to anyone but an administrator is not something that we'd implement. Similarly for an API call that listed all unavailable IDs.

Revision history for this message
Wallace Cardoso (wallacec) said :

Thanks for the detailed answers. Help me a lot. Thanks in advance.