Can't re-use an ID from a previously deleted image

Bug #1176978 reported by Sébastien Han
This bug affects 11 people
Affects Status Importance Assigned to Milestone
Won't Fix

Bug Description

Hi all,

Steps to reproduce it:

$ glance image-create --name foo
| Property | Value |
| checksum | None |
| container_format | None |
| created_at | 2013-05-06T16:08:34 |
| deleted | False |
| deleted_at | None |
| disk_format | None |
| id | c3313eda-f6dd-4062-85c8-7ab1bb168cd1 |
| is_public | False |
| min_disk | 0 |
| min_ram | 0 |
| name | foo |
| owner | 19292b3b597b4ecc9a41103cc312a42f |
| protected | False |
| size | 0 |
| status | queued |
| updated_at | 2013-05-06T16:08:34 |

$ glance image-delete c3313eda-f6dd-4062-85c8-7ab1bb168cd1

$ glance image-create --name foo --id c3313eda-f6dd-4062-85c8-7ab1bb168cd1
Request returned failure status.
409 Conflict
An image with identifier c3313eda-f6dd-4062-85c8-7ab1bb168cd1 already exists
    (HTTP 409)

I use the grizzly stable branch from Ubuntu cloud archive, same behavior on the debian packages.


Revision history for this message
xingzhou (xingzhou) wrote :

From my view of the design, when storing images in glance, there will be a status field which identifies whether the image is deleted, if so, the image id is still in DB and as a result, there would be duplicate id returned. But I think the response message should be enhanced in order to avoid confusion

Revision history for this message
Sébastien Han (sebastien-han) wrote :

I'm confused, why looking at the field if the status is deleted? The image doesn't exist anymore so the ID must be available.

Revision history for this message
xingzhou (xingzhou) wrote :

There is a brief introduction for image status management, fyi:

Revision history for this message
xingzhou (xingzhou) wrote :

furthermore, some images in deleted status can be recovered, I'm thinking for this purpose, to keep the image and its metadata is useful

xingzhou (xingzhou)
Changed in glance:
status: New → Invalid
Feilong Wang (flwang)
Changed in glance:
status: Invalid → In Progress
assignee: nobody → Fei Long Wang (flwang)
Revision history for this message
Feilong Wang (flwang) wrote :

(07:46:34 AM) flwang: btw, may I get your thought about this defect?
(07:47:48 AM) flwang: about if the image id should be reused after the image is deleted
(07:49:18 AM) flaper87: flwang: it shouldn't, images are never *truly* deleted, see
(07:49:27 AM) flwang: I see
(07:49:39 AM) flaper87: that's the BaseModel
(07:49:43 AM) flwang: I know it's just marked 1 in the deleted column
(07:49:45 AM) flaper87: and Image inherits from it
(07:49:52 AM) flaper87: correct
(07:50:21 AM) flaper87: there were some discussions about completely delelting those images (cleaning up the db)
(07:50:23 AM) flwang: now there is a scenario
(07:50:34 AM) flaper87: but nothing has been decided yet
(07:51:28 AM) flaper87: TBH, I don't like the idea of people passing the id on the create command, but that's another story for another time
(07:51:30 AM) flwang: user is porting some images from vmware vcenter, and then these images are deleted
(07:51:49 AM) flaper87: flwang: not sure I understand
(07:52:00 AM) flaper87: flwang: you mean, import image from vmware into glance
(07:52:04 AM) flwang: but next, user want to add these images again with the image id given by vcenter
(07:52:05 AM) flaper87: then delete image in glance
(07:52:09 AM) flwang: yes
(07:53:20 AM) flwang: anyway, if user want to re-register an image with its given id from other place, he will run into problem based on current code
(07:54:10 AM) flaper87: flwang: yep, I guess passing the ID makes sense when you've 3K services pointing to that specific ID and you want them to use glance
(07:54:35 AM) flwang: exactly
(07:55:19 AM) flaper87: mmh, interesting. I'm trying to find the bp / discussion about "really deleting" images. I can't find it
(07:58:04 AM) flwang: for short term, I want to reuse the id
(07:59:03 AM) flwang: when create new image, glance will try to check if there is a dead image if there is a given image id
(07:59:14 AM) flwang: if yes, reuse id
(07:59:55 AM) flwang: any concern?
(08:00:01 AM) flaper87: might make sense. It would be cool if you could write this to the mailing list so that other folks can comment. Make sure your point the use-cases and ideas there
(08:00:19 AM) ***flaper87 is still trying to find that stuff
(08:00:22 AM) flaper87: arrgh
(08:00:24 AM) flaper87: internet is sooo big
(08:02:23 AM) flwang: good suggestion, I will send it to mailing list. Actually, I have worked out the patch, and I think it works fine.
(08:03:57 AM) flaper87: If you have some code to show, I'd suggest to either push it somewhere in GH or submitting the patch (thing is that this change, most likely, requires a blueprint so, I'd rather get some feedback before going down that road)
(08:13:45 AM) flwang: I'm going to submit the patch as the fix of this bug, make sense?
(08:14:30 AM) flaper87: mmh, yeah, that makes sense. Expect some discussions, though.

Revision history for this message
Sébastien Han (sebastien-han) wrote :

Good to know that some process have been made :)

Revision history for this message
Matteo Panella (mpanella) wrote :

This issue also affects glance-replicator in a peculiar way: if an image is deleted from the slave glance instance it will be considered as already existing and it won't be redownloaded from the master.

I'm not sure if I should file a separate issue for glance-replicator which depends on this one, though.

Revision history for this message
Feilong Wang (flwang) wrote :

Matteo, thanks for update the info. I think it's a good user case to pushing this change, since the core team is hesitating if we need this :)

It's ok to open a separate bug and then link to this one, up to you.

BTW, what's your expected behavior to reuse the image id? Do you think a new argument "allow-image-id-reused" is an option?

Revision history for this message
Mark Washenberger (markwash) wrote :

Being allowed to specify the id of an image is restricted by policy, so I don't see a risk in just fixing this bug in the most straightforward way.

Revision history for this message
Feilong Wang (flwang) wrote :

Mark, thanks for the comments. But now I'm considering a scenario which may break something if we just simple enable this. For example, if there is an image A and an instance has been created based on it. Then image A is deleted. User want to reuse the image id and upload a new image (data). As a result, there maybe two instances created by the same image (id) but has different content.

In other words, we may need some restrict conditions for the user.

Feilong Wang (flwang)
Changed in glance:
importance: Undecided → Wishlist
Erno Kuvaja (jokke)
tags: added: propose-close
Changed in glance:
assignee: Fei Long Wang (flwang) → nobody
status: In Progress → New
Revision history for this message
Abel Lopez (al592b) wrote :

Why is this being discussed? It's a pretty blatant violation of the UUID and Primary Key concepts.
I guess the long story revolves around our soft-delete practices, in which deleted entities remain in the database as "deleted=1".
So, since we're trying to re-user the UUID, and it's the PK in the images DB, this fails.
However, if you were to clean up the DB, say 'delete from images where deleted=1', you could then re-use the UUID.

I still think it's bad practice, IMO, to re-use the UUID, as images are meant to be immutable, any updates to the image should get a new UUID, and any new image should as well.

Maybe the users want an 'undelete' call?

Revision history for this message
Ian Cordasco (icordasc) wrote :

Abel, I tend to agree. It does violate the idea of a UUID. As it is, I'm -1 on allowing a UUID to be resued unless we were to give users a way to purge the database. I'm in favor of marking this as a won't fix item since it isn't really a bug anyway.

Changed in glance:
importance: Wishlist → Undecided
Revision history for this message
Erno Kuvaja (jokke) wrote :

As there has bee no progress and valid concerns regarding UUID concept, closing this as Won't fix. Works as designed and IMO if there is need for this behaviour it should come through spec, not a bug.

Changed in glance:
status: New → Won't Fix
Revision history for this message
György Szombathelyi (gyurco) wrote :

I think it's very confusing to allow a user to specify an UUID, yet fail when an already deleted UUID is to be re-used, without any clue why did it fail.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.