[openstack-dev] [nova] Super fun unshelve image_ref bugs

Matt Riedemann mriedemos at gmail.com
Wed Sep 19 16:57:30 UTC 2018

On 12/1/2017 2:47 PM, Matt Riedemann wrote:
> Andrew Laski also mentioned in IRC that we didn't replace the original 
> instance.image_ref with the shelved image id because the shelve 
> operation should be transparent to the end user, they have the same 
> image (not really), same volumes, same IPs, etc once they unshelve. And 
> he mentioned that if you rebuild, for example, you'd then rebuild to the 
> original image instead of the shelved snapshot image.
> I'm not sure how much I agree with that rebuild argument. I understand 
> it, but I'm not sure I agree with it. I think it's much easier to just 
> track things for what they are, which means saying if you create a guest 
> from a given image id, then track that in the instances table, don't lie 
> about it being something else.

Dredging this back up since it will affect cross-cell resize which will 
rely on shelve/unshelve.

I had a thought recently (and noted in 
https://bugs.launchpad.net/nova/+bug/1732428) that the RequestSpec 
points at the original image used to create the server, or last rebuild 
it (if the server was rebuilt with a new image). What if we used that 
during rebuilds rather than the instance.image_ref?

Then unshelve could leave the instance.image_ref pointing at the shelve 
snapshot image (since that's what is actually backing the server at the 
time of unshelve and should fix the resize qcow2 bug linked above) but 
rebuild could still rebuild from the original (or last rebuild) image 
rather than the shelve snapshot image?

The only hiccup I'm aware of is we then still need to *not* delete the 
snapshot image on unshelve that the instance is pointing at, which means 
shelve snapshot images could pile up over time, especially with 
cross-cell resize. Is that a problem? If so, could we have a periodic 
that cleans up the old snapshot images based on some configured value?




More information about the OpenStack-dev mailing list