That is a very real concern. This I systems from images being named very uniquely, with versions, dates, etc. To the end user this is ALMOST as hard as a UUID. <div>Easy/generic names encourage users to use them, but there is an aspect of documentation and user training/education on the proper use of name-based automation. <span></span><br><div><br>On Thursday, February 5, 2015, Marc Heckmann <<a href="mailto:marc.heckmann@ubisoft.com">marc.heckmann@ubisoft.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 2015-02-05 at 06:02 -0800, Abel Lopez wrote:<br>
> I always recommend the following:<br>
> All public images are named generically enough that they can be<br>
> replaced with a new version of the same name. This helps new instances<br>
> booting.<br>
> The prior image is renamed with -OLD-$date. This lets users know that<br>
> their image has been deprecated. This image is made private so no new<br>
> instances can be launched.<br>
> All images include an updated motd that indicates available security<br>
> updates.<br>
<br>
I like this approach, but I have the following caveat: What if users are<br>
using the uuid of the image instead of the name in some automation<br>
scripts that they might have? If we make the "-OLD-$date" images<br>
private, then we just broke their scripts.<br>
<br>
><br>
><br>
> We're discussing baking the images with automatic updates, but still<br>
> haven't reached an agreement.<br>
><br>
> On Thursday, February 5, 2015, Tim Bell <<a href="javascript:;" onclick="_e(event, 'cvml', 'Tim.Bell@cern.ch')">Tim.Bell@cern.ch</a>> wrote:<br>
> > -----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<br>
> public images?<br>
> ><br>
> > Hello everyone.<br>
> ><br>
> > We are updating our public images regularly (to provide them<br>
> to customers in<br>
> > up-to-date state). But there is a problem: If some instance<br>
> 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<br>
> 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<br>
> compute node)<br>
> ><br>
> > One more (our specific):<br>
> > We're using raw disks with _base on slow SATA drives (in<br>
> comparison to fast SSD<br>
> > for disks), and if that SATA fails, we replace it (and nova<br>
> redownloads stuff in<br>
> > _base).<br>
> ><br>
> > If image is deleted, it causes problems with nova (nova<br>
> can't download _base).<br>
> ><br>
> > The second part of the problem: glance disallows to update<br>
> image (upload new<br>
> > image with same ID), so we're forced to upload updated image<br>
> 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<br>
> 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,<br>
> we've defined a panel using image meta data. Details are at<br>
> <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<br>
> 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<br>
> hidden so that it can still be used for snapshots/migration<br>
> 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>
> ><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>
> _______________________________________________<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>
</blockquote></div></div>