Everyone: let's consider John's suggestion carefully. I was going to hold off on the service token stuff for later in the interest of getting a fix to this bug out, but obviously the proposal on the spec is so freaking complicated that complexity of the fix is no longer an issue.
@John: your PS: the problem is small deployments with only one Glance requires exposing setting the locations, so even though it should be admin only, it's open to users. Your service-token proposal would address this.
@John: your PPS: the original user's image would keep the reference count for the data at > 0, so even if someone guessed/learned the location, set it on an image, and deleted the image, Glance wouldn't try to delete the data out of the backend. On the other hand, this is a data leakage scenario that I don't like, and I think we should prevent it. So that's another reason to prohibit multiple image records from containing the same location.
Thanks, John.
Everyone: let's consider John's suggestion carefully. I was going to hold off on the service token stuff for later in the interest of getting a fix to this bug out, but obviously the proposal on the spec is so freaking complicated that complexity of the fix is no longer an issue.
@John: your PS: the problem is small deployments with only one Glance requires exposing setting the locations, so even though it should be admin only, it's open to users. Your service-token proposal would address this.
@John: your PPS: the original user's image would keep the reference count for the data at > 0, so even if someone guessed/learned the location, set it on an image, and deleted the image, Glance wouldn't try to delete the data out of the backend. On the other hand, this is a data leakage scenario that I don't like, and I think we should prevent it. So that's another reason to prohibit multiple image records from containing the same location.