I always recommend the following:<div>All public images are named generically enough that they can be replaced with a new version of the same name. This helps new instances booting. </div><div>The prior image is renamed with -OLD-$date. This lets users know that their image has been deprecated. This image is made private so no new instances can be launched. </div><div>All images include an updated motd that indicates available security updates. </div><div><br></div><div>We're discussing baking the images with automatic updates, but still haven't reached an agreement. <span></span><br><br>On Thursday, February 5, 2015, Tim Bell <<a href="mailto:Tim.Bell@cern.ch">Tim.Bell@cern.ch</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> -----Original Message-----<br>
> From: George Shuklin [mailto:<a href="javascript:;" onclick="_e(event, 'cvml', 'george.shuklin@gmail.com')">george.shuklin@gmail.com</a>]<br>
> Sent: 05 February 2015 14:10<br>
> To: <a href="javascript:;" onclick="_e(event, 'cvml', 'openstack-operators@lists.openstack.org')">openstack-operators@lists.openstack.org</a><br>
> Subject: [Openstack-operators] How to handle updates of public images?<br>
><br>
> Hello everyone.<br>
><br>
> We are updating our public images regularly (to provide them to customers in<br>
> up-to-date state). But there is a problem: If some instance starts from image it<br>
> 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>
> One more (our specific):<br>
> We're using raw disks with _base on slow SATA drives (in comparison to fast SSD<br>
> for disks), and if that SATA fails, we replace it (and nova redownloads stuff in<br>
> _base).<br>
><br>
> If image is deleted, it causes problems with nova (nova can't download _base).<br>
><br>
> The second part of the problem: glance disallows to update image (upload new<br>
> image with same ID), so we're forced to upload updated image with new ID and<br>
> to remove the old one. This causes problems described above.<br>
> And if tenant boots from own snapshot and removes snapshot without removing<br>
> instance, it causes same problem even without our activity.<br>
><br>
> How do you handle public image updates in your case?<br>
><br>
<br>
We have a similar problem. For the Horizon based end users, we've defined a panel using image meta data. Details are at <a href="http://openstack-in-production.blogspot.ch/2015/02/choosing-right-image.html" target="_blank">http://openstack-in-production.blogspot.ch/2015/02/choosing-right-image.html</a>.<br>
<br>
For the CLI users, we propose to use the sort options from Glance to find the latest image of a particular OS.<br>
<br>
It would be good if there was a way of marking an image as hidden so that it can still be used for snapshots/migration but would not be shown in image list operations.<br>
<br>
> Thanks!<br>
><br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', '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>
OpenStack-operators mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', '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>
</blockquote></div>