Comment 9 for bug 1990157

Erno, that's a good idea to re-hash the image when we add the location, but:

1. We'd probably want some way to not expose that location until it's verified, otherwise we've just shrunk the window. I don't think we have a "state" for each location today, do we?

2. It would probably be difficult to expose the result of a failure. Accidental tripping of the hash failure would result in locations just disappearing (I assume) which could be confusing.

3. We'd need some way to recover the process if we're interrupted in the middle of reading a very large image. If we had #1, then perhaps the location would never become usable, but we'd need to cover that case.

4. We'd end up with a very large additional load on glance-api that isn't there today, as all the (currently very lightweight) snapshotting of nova instances would cause a lot of additional CPU and network load to glance. Right now, you can snapshot your instances very frequently on ceph because it's so lightweight, and people do. On an edge deployment where you've got a local glance, that could end up overwhelming what is actually just a very lightweight set of glance workers for the (current) purpose of just finding images in RBD.

So, it might be worth doing this anyway, but I think we'd want to hide that behind a "verify_additional_locations=(True|False)" flag for the security-conscious. For people that don't want that level of additional work, deploying glance internal and public would be a lot better I think as it closes the hole and avoids a bunch of additional work on each snapshot.