Comment 125 for bug 1546507

I've been thinking about Cinder. I think the scheme proposed in the spec is vulnerable to the following exploit when Cinder is being used in multi-tenant mode:

1 Tenant A creates Image 1234 with location cinder://whatever (and Tenant A owns this data)
2 Tenant B creates Image 2222 with location cinder://whatever
3 Tenant A deletes Image 1234. Glance doesn't try to delete cinder://whatever because the location_count is non-zero
4 (Tenant A is now paying for storage of image data he's "deleted", but we'll ignore that.)
5 Tenant B deletes Image 2222. The location_counter for cinder://whatever is now zero, so Glance tries to delete cinder://whatever. This will fail because Tenant B does not own cinder://whatever, so cinder will not allow the volume to be deleted.

As a result, the scheme in the spec is vulnerable to leaving around a lot of "dark data".

My conclusion is that I'm beginning to think that we've gone overboard with this reference counting business, and that we should simply disallow multiple images using the same location. Those "legitimate scenarios" for multiple Glance image records referring to the same location resolve around the autoscale case, and nowadays autoscale is falling out of favor and people are using containers instead.

I think we should simplify the proposal. We'll still need to normalize the locations URIs for some of the backends, and we'll need to do the hashing to allow for quick lookups/uniqueness on the location, but maybe we can do that by adding an indexed column to the 'image_locations' table. Maybe we can get away with not having the to_be_deleted table, too?