[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