<div dir="ltr"><div>We don't delete public images from Glance because it breaks migrate/resize and block live migration. Not tested with upstream Kilo, though.</div><div>As consequence, our public image list has been growing over time...</div><div><br></div><div>In order to manage image releases we use "glance image properties" to tag them.<br></div><div><br></div><div>Some relevant reviews:</div><div><a href="https://review.openstack.org/#/c/150337/">https://review.openstack.org/#/c/150337/</a><br></div><div><a href="https://review.openstack.org/#/c/90321/">https://review.openstack.org/#/c/90321/</a><br></div><div><br></div><div><div>Belmiro</div><div>CERN</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 5, 2015 at 8:16 PM, Kris G. Lindgren <span dir="ltr"><<a href="mailto:klindgren@godaddy.com" target="_blank">klindgren@godaddy.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In the case of a raw backed qcow2 image (pretty sure that¹s the default)<br>
the instances root disk as seen inside the vm is made up of changes made<br>
on the instance disk (qcow2 layer) + the base image (raw).  Also, remember<br>
that as currently coded a resize migration will almost always be a<br>
migrate.  However, since the vm is successfully running on the old compute<br>
node it *should* be a trivial change that if the backing image is no<br>
longer available via glance - copy that over to the new host as well.<br>
____________________________________________<br>
<br>
Kris Lindgren<br>
Senior Linux Systems Engineer<br>
GoDaddy, LLC.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On 2/5/15, 11:55 AM, "Clint Byrum" <<a href="mailto:clint@fewbar.com">clint@fewbar.com</a>> wrote:<br>
<br>
>Excerpts from George Shuklin's message of 2015-02-05 05:09:51 -0800:<br>
>> Hello everyone.<br>
>><br>
>> We are updating our public images regularly (to provide them to<br>
>> customers in up-to-date state). But there is a problem: If some<br>
>>instance<br>
>> starts from image it becomes 'used'. That means:<br>
>> * That image is used as _base for nova<br>
>> * If instance is reverted this image is used to recreate instance's disk<br>
>> * If instance is rescued this image is used as rescue base<br>
>> * It is redownloaded during resize/migration (on a new compute node)<br>
>><br>
><br>
>Some thoughts:<br>
><br>
>* All of the operations described should be operating on an image ID. So<br>
>the other suggestions of renaming seems the right way to go. "Ubuntu<br>
>14.04" becomes "Ubuntu 14.04 02052015" and the ID remains in the system<br>
>for a while. If something inside Nova doesn't work with IDs, it seems<br>
>like a bug.<br>
><br>
>* rebuild, revert, rescue, and resize, are all very _not_ cloud things<br>
>that increase the complexity of Nova. Perhaps we should all reconsider<br>
>their usefulness and encourage our users to spin up new resources, use<br>
>volumes and/or backup/restore methods, and then tear down old instances.<br>
><br>
>One way to encourage them is to make it clear that these operations will<br>
>only work for X amount of time before old versions images will be removed.<br>
>So if you spin up Ubuntu 14.04 today, reverts and resizes and rescues<br>
>are only guaranteed to work for 6 months. Then aggressively clean up ><br>
>6 month old image ids. To make this practical, you might even require<br>
>a role, something like "reverter", "rescuer", "resizer" and only allow<br>
>those roles to do these operations, and then before purging images,<br>
>notify those users in those roles of instances they won't be able to<br>
>resize/rescue/revert anymore.<br>
><br>
>It also makes no sense to me why migrating an instance requires its<br>
>original image. The instance root disk is all that should matter.<br>
><br>
>_______________________________________________<br>
>OpenStack-operators mailing list<br>
><a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div></div></blockquote></div><br></div>