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

Matt Riedemann mriedemos at gmail.com
Fri Dec 1 20:47:04 UTC 2017


On 12/1/2017 1:25 PM, Mathieu Gagné wrote:
> Hi,
> 
> On Fri, Dec 1, 2017 at 12:24 PM, Matt Riedemann <mriedemos at gmail.com> wrote:
>>
>> I think we can assert as follows:
>>
>> 2. If we're going to point the instance at an image_ref, we shouldn't delete
>> that image. I don't have a good reason why besides deleting things which
>> nova has a reference to in an active instance generally causes problems
>> (volumes, ports, etc).
>>
> 
> Not 100% related to your initial problem but...
> 
> Does it mean that you still shouldn't delete any images in Glance
> until you are 100% sure that NO instances use them?
> If you shouldn't ever delete an image, are there any plans to address
> it in the future? Or is it a known "limitation" that people just have
> to live with?
> If you can delete an image used by one or more instances, how is
> shelving affected or different? Should it not be affected?
> 

I'm not sure honestly. I know a snapshot image has a reference to the 
instance uuid that created it, but I don't know if there are any 
restrictions on the glance side from deleting those images before the 
image is fully uploaded and active, something like that.

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.

-- 

Thanks,

Matt



More information about the OpenStack-dev mailing list