I think the asynchronous hash calculation can be approached 2 ways:
1) We don't let the image go to "active" before the multihash has been calculated. This would indeed break anything that currently depends on snapshot being immediately available and slow thing down significantly.
2) We let the new image behave just like it does now, but we also kick off the task to calculate the checksum and populate that to the image once it's done.
Then any additional location added via the API would be deferred until it's checksum has been verified. This is no extra work when the 'copy-image' import method is used as it's doing this already and at least I do not know any current usage where additional locations would be added to the image record "manually" apart from the said malicious activity.
As the COW consumers are not interested to check the hash anyways, I'd be n favour of #2 that would not be blocking the current legitimate usage patterns but would provide both user and Glance way to verify that the data is intact. Should consumers ever change their attitude on this, they could just have a logic that starts calculating their own hash and does the comparison once Glance has updated the record in it's database.
I think the asynchronous hash calculation can be approached 2 ways:
1) We don't let the image go to "active" before the multihash has been calculated. This would indeed break anything that currently depends on snapshot being immediately available and slow thing down significantly.
2) We let the new image behave just like it does now, but we also kick off the task to calculate the checksum and populate that to the image once it's done.
Then any additional location added via the API would be deferred until it's checksum has been verified. This is no extra work when the 'copy-image' import method is used as it's doing this already and at least I do not know any current usage where additional locations would be added to the image record "manually" apart from the said malicious activity.
As the COW consumers are not interested to check the hash anyways, I'd be n favour of #2 that would not be blocking the current legitimate usage patterns but would provide both user and Glance way to verify that the data is intact. Should consumers ever change their attitude on this, they could just have a logic that starts calculating their own hash and does the comparison once Glance has updated the record in it's database.