[Openstack-operators] How to handle updates of public images?

Clint Byrum clint at fewbar.com
Thu Feb 5 18:55:50 UTC 2015

Excerpts from George Shuklin's message of 2015-02-05 05:09:51 -0800:
> Hello everyone.
> We are updating our public images regularly (to provide them to 
> customers in up-to-date state). But there is a problem: If some instance 
> starts from image it becomes 'used'. That means:
> * That image is used as _base for nova
> * If instance is reverted this image is used to recreate instance's disk
> * If instance is rescued this image is used as rescue base
> * It is redownloaded during resize/migration (on a new compute node)

Some thoughts:

* All of the operations described should be operating on an image ID. So
the other suggestions of renaming seems the right way to go. "Ubuntu
14.04" becomes "Ubuntu 14.04 02052015" and the ID remains in the system
for a while. If something inside Nova doesn't work with IDs, it seems
like a bug.

* rebuild, revert, rescue, and resize, are all very _not_ cloud things
that increase the complexity of Nova. Perhaps we should all reconsider
their usefulness and encourage our users to spin up new resources, use
volumes and/or backup/restore methods, and then tear down old instances.

One way to encourage them is to make it clear that these operations will
only work for X amount of time before old versions images will be removed.
So if you spin up Ubuntu 14.04 today, reverts and resizes and rescues
are only guaranteed to work for 6 months. Then aggressively clean up >
6 month old image ids. To make this practical, you might even require
a role, something like "reverter", "rescuer", "resizer" and only allow
those roles to do these operations, and then before purging images,
notify those users in those roles of instances they won't be able to
resize/rescue/revert anymore.

It also makes no sense to me why migrating an instance requires its
original image. The instance root disk is all that should matter.

More information about the OpenStack-operators mailing list