<div dir="ltr">We do exactly this.<div><br></div><div>Public images are named very generically like "Ubuntu 14.04". Not even "14.04.1" or something like that. Old images are renamed and made private. Existing instances continue to run, but, as others have mentioned, if a user is using a  UUID to launch instances, that will break for them. This is an acceptable trade-offf or us. Our documentation makes mention of this and to use the names. </div><div><br></div><div>The OpenStack CLI tools as well as Vagrant (the two most used non-Dashboard tools that are used) both support image names, so we haven't run into a UUID-only issue.</div><div><br></div><div>We have a modified MOTD that lists some different scripts that the user can run, such as:</div><div><br></div><div>* Using our local apt-cache server (Ubuntu only)</div><div>* Enabling automatic updates</div><div>* Install the openstack command-line tools</div><div><br></div><div>We had a few debates about turning on automatic updates in the images we provide. Ultimately we chose to not enable them and instead go with the MOTD message. There are several reasons why having automatic updates enabled is a benefit, but the single reason that made us not do it is simply "if an automatic update breaks the user's instance, it's our fault." It's a very debatable argument.</div><div><br></div><div>Also, we use Packer to bundle all of this. We have most of it available here:</div><div><br></div><div><a href="https://github.com/cybera/openstack-images">https://github.com/cybera/openstack-images</a><br></div><div><br></div><div>In addition to all of this, we allow users to upload their own images. So if the core set of images we provide doesn't meet their needs, they're free to do create their own solution.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 5, 2015 at 7:02 AM, Abel Lopez <span dir="ltr"><<a href="mailto:alopgeek@gmail.com" target="_blank">alopgeek@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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. <div><div class="h5"><span></span><br><br>On Thursday, February 5, 2015, Tim Bell <<a href="mailto:Tim.Bell@cern.ch" target="_blank">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>george.shuklin@gmail.com</a>]<br>
> Sent: 05 February 2015 14:10<br>
> To: <a>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>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>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></div></div>
<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></blockquote></div><br></div>