> @Dan we do have status on the locations table and we do update it. I don't think we consume it
> anywhere currently but it's there.
Okay fair enough. I guess we could make nova look at that, but I'm not sure what we'd do really. Maybe only consider the non-hashing ones and potentially download the image and duplicate it in RBD on boots that complete before a new location is available. Could work, but also probably confusing for people that wonder why some of their instances aren't doing COW from the base image. Some thinking on how best to handle that is probably required.
> Don't we also have the error metadata key where we already report errors from the import tasks,
> maybe we can reuse that?
Yup, and I suppose we could, or another similar one for locations specifically. But if we've got status on a location, that it is probably enough.
> Plus, if the hash isn't going to be checked by nova when the image is consumed, recomputing it
> for each location seems kind of pointless
Making nova check the hash before the boot is definitely counterproductive to the goal of fast COW boots. However, I think (one of) the benefit(s) of what Erno is proposing is that glance checks it once for the benefit of everyone and then we can trust it going forward. I think it would generate an intolerable amount of glance CPU and network traffic, but it would certainly be less than every nova checking it every time.
I agree with Brian's #4 and Erno's @All above. The most important thing is getting the tribal knowledge of how glance should be deployed out to the wider audience. Other things we can do between glance, nova and cinder to make this better in the future will take time, and likely have drawbacks that make them undesirable and/or hard to backport. Even if we implement some better hashing and verification, I suspect a lot of people would prefer to deploy two glance APIs, rely on host-level security for who can add locations, and trust that images created from behind the firewall are what they say they are.
> @Dan we do have status on the locations table and we do update it. I don't think we consume it
> anywhere currently but it's there.
Okay fair enough. I guess we could make nova look at that, but I'm not sure what we'd do really. Maybe only consider the non-hashing ones and potentially download the image and duplicate it in RBD on boots that complete before a new location is available. Could work, but also probably confusing for people that wonder why some of their instances aren't doing COW from the base image. Some thinking on how best to handle that is probably required.
> Don't we also have the error metadata key where we already report errors from the import tasks,
> maybe we can reuse that?
Yup, and I suppose we could, or another similar one for locations specifically. But if we've got status on a location, that it is probably enough.
> Plus, if the hash isn't going to be checked by nova when the image is consumed, recomputing it
> for each location seems kind of pointless
Making nova check the hash before the boot is definitely counterproductive to the goal of fast COW boots. However, I think (one of) the benefit(s) of what Erno is proposing is that glance checks it once for the benefit of everyone and then we can trust it going forward. I think it would generate an intolerable amount of glance CPU and network traffic, but it would certainly be less than every nova checking it every time.
I agree with Brian's #4 and Erno's @All above. The most important thing is getting the tribal knowledge of how glance should be deployed out to the wider audience. Other things we can do between glance, nova and cinder to make this better in the future will take time, and likely have drawbacks that make them undesirable and/or hard to backport. Even if we implement some better hashing and verification, I suspect a lot of people would prefer to deploy two glance APIs, rely on host-level security for who can add locations, and trust that images created from behind the firewall are what they say they are.