Shelved instance image/snapshot is not protected from deletion

Bug #1807110 reported by Trent Lloyd
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Opinion
Wishlist
Unassigned

Bug Description

When shelving an instance with nova storage (instead of boot from volume), a glance snapshot of the VM is created before it is shelved.

The user is free to delete this snapshot with no warning, indication or error that the snapshot is needed by the shelved instance other than the name (being VMNAME-shelved).

Shelved images should be protected from deletion, ideally by indicating they are in use by the shelved instance or at the very least we could set (and perhaps not allow unsetting) the 'protected' flag.

This results in data loss when the user inadvertently deletes the snapshot, not realizing it is required for the shelved instance. While it's technically user-induced and not spontaneous, a reasonable user would expect a warning or indication in such a case.

This bug probably crosses over into glance rather than just nova, however, nova would likely need to at least partially orchestrate such a protection, so I am filing the bug against nova initially.

== Steps to reproduce ==
 (1) openstack server create --flavor m1.small --image xenial --network tenant --wait test-a
 (2) openstack shelve test-a # wait
 (3) openstack image delete test-a-shelved --wait # Received: NO ERROR, Expected: ERROR
 (4) openstack server unshelve test-a # ERROR (cannot find image)

Tags: shelve
Matt Riedemann (mriedem)
tags: added: shelve
Revision history for this message
Matt Riedemann (mriedem) wrote :

Hmm, this is an interesting point. Setting the protected=true flag on the image seems like a good solution, except I don't see any kind of force delete option for images. Would a user be able to change the protected value from true to false if they really knew what they were doing and wanted to delete the snapshot image? It's unclear to me from reading the docs on updating an image and the image schema:

https://developer.openstack.org/api-ref/image/v2/index.html#update-image

https://developer.openstack.org/api-ref/image/v2/index.html#show-image-schema

This should probably be discussed on the mailing list to get wider input as this would also be an API behavior change for shelve.

Changed in nova:
status: New → Opinion
importance: Undecided → Wishlist
Revision history for this message
Matt Riedemann (mriedem) wrote :
Revision history for this message
Anastasios (adados) wrote :

Hello,
We have Libery version and we have experienced the same issue recently.
In the "openstack image set" help list it's indicating that the unprotected status is by default enabled so i guess from glance point of view it's an expected behaviour on setting the status of the shelved image to "unprotected" when it's being created but it shouldn't be like that:

--protected Prevent image from being deleted
--unprotected Allow image to be deleted (default)

So yes the user can accidentally deletes the image as you say which will have a permanent data loss of his instance in case he tries to unshelve it. The user can set/unset the protected mode of the image whenever he want as well.

Regarding your thread in the openstack forum and what you mentioned in the end:

"The other problem with nova marking the image as protected is that if
the user deletes the server, the compute API tries to delete the
snapshot image [1] which would fail if it's still protected, and then we
could see snapshot images getting orphaned in glance. Arguably nova
could detect this situation, update the protected field to false, and
then delete the image."

I tested this (with protected status on) and I indeed deleted the instance but then the image stayed there and then i had to manually change the status to unprotected again so that it will be eligible for delete again.

Looking forward for more feedback from others as well.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.