I'm curious: are you using _base files? We're not and we're able to block migrate instances based on deleted images or images that were public but are now private.
On Thu, Feb 5, 2015 at 2:42 PM, Belmiro Moreira < moreira.belmiro.email.li...@gmail.com> wrote: > We don't delete public images from Glance because it breaks migrate/resize > and block live migration. Not tested with upstream Kilo, though. > As consequence, our public image list has been growing over time... > > In order to manage image releases we use "glance image properties" to tag > them. > > Some relevant reviews: > https://review.openstack.org/#/c/150337/ > https://review.openstack.org/#/c/90321/ > > Belmiro > CERN > > On Thu, Feb 5, 2015 at 8:16 PM, Kris G. Lindgren <klindg...@godaddy.com> > wrote: > >> In the case of a raw backed qcow2 image (pretty sure that¹s the default) >> the instances root disk as seen inside the vm is made up of changes made >> on the instance disk (qcow2 layer) + the base image (raw). Also, remember >> that as currently coded a resize migration will almost always be a >> migrate. However, since the vm is successfully running on the old compute >> node it *should* be a trivial change that if the backing image is no >> longer available via glance - copy that over to the new host as well. >> ____________________________________________ >> >> Kris Lindgren >> Senior Linux Systems Engineer >> GoDaddy, LLC. >> >> >> >> >> On 2/5/15, 11:55 AM, "Clint Byrum" <cl...@fewbar.com> wrote: >> >> >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. >> > >> >_______________________________________________ >> >OpenStack-operators mailing list >> >OpenStack-operators@lists.openstack.org >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> >> _______________________________________________ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> > > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
