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

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

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.

There is a brief introduction for image status management, fyi:
http://docs.openstack.org/developer/glance/statuses.html

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

(07:46:34 AM) flwang: btw, may I get your thought about this defect? https://bugs.launchpad.net/glance/+bug/1176978
(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 https://github.com/openstack/glance/blob/master/glance/db/sqlalchemy/models.py#L65
(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.

Good to know that some process have been made :)

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.

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?

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.

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.

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?

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.

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.

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.