© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
The history of code around this bug goes back to defect:
https:/
because of security issue the code was modified as follows:
step 1: Update image metadata with status = deleted
step 2: mark image in db as deleted=true and deleted_at = time
step 3: delete the image from backend
as per comment: https:/
Later there was a bug filed https:/
Here they claimed, if deleting image from backend failed then
users can not use glance image-delete command to clean up the orphan image in backend.
For this purpose code was changed as follows:
step 1: Update image metadata with status = deleted
step 2: delete the image from backend
step 3: mark image in db as deleted=true and deleted_at = time
Now this bug points that what if, image metadata delete from db fails..
On closely looking at v2 api flow:
glance v2 checks the authorization with policy.json to allow delete action
deletes the image from backend
mark image in db as deleted=true and deleted_at = time
To maintain consistency between v1 and v2,
keeping v2 flow as reference in v1 we will do following:
step 1: try image metadata update status=[current image status]
if the above update fails that means user is not allowed to update the image and hence delete action will error
step 2: Then delete the image from backend
step 3: if, its successful, set the image status=pending delete/deleted, deleted=true and deleted_
Alternatively, we could delete the image metadata from db first so that the image is not at all usable
and then try deleting from backend, if, backend fails there can be an error message specifying what to do.
Looking forward to suggestions on this, so that I can proceed with the fix.