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. 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.
On Thursday, February 5, 2015, Marc Heckmann <marc.heckm...@ubisoft.com> wrote: > On Thu, 2015-02-05 at 06:02 -0800, Abel Lopez wrote: > > I always recommend the following: > > 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. > > 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. > > All images include an updated motd that indicates available security > > updates. > > I like this approach, but I have the following caveat: What if users are > using the uuid of the image instead of the name in some automation > scripts that they might have? If we make the "-OLD-$date" images > private, then we just broke their scripts. > > > > > > > We're discussing baking the images with automatic updates, but still > > haven't reached an agreement. > > > > On Thursday, February 5, 2015, Tim Bell <tim.b...@cern.ch <javascript:;>> > wrote: > > > -----Original Message----- > > > From: George Shuklin [mailto:george.shuk...@gmail.com > <javascript:;>] > > > Sent: 05 February 2015 14:10 > > > To: openstack-operators@lists.openstack.org <javascript:;> > > > Subject: [Openstack-operators] How to handle updates of > > public images? > > > > > > 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) > > > > > > One more (our specific): > > > We're using raw disks with _base on slow SATA drives (in > > comparison to fast SSD > > > for disks), and if that SATA fails, we replace it (and nova > > redownloads stuff in > > > _base). > > > > > > If image is deleted, it causes problems with nova (nova > > can't download _base). > > > > > > The second part of the problem: glance disallows to update > > image (upload new > > > image with same ID), so we're forced to upload updated image > > with new ID and > > > to remove the old one. This causes problems described above. > > > And if tenant boots from own snapshot and removes snapshot > > without removing > > > instance, it causes same problem even without our activity. > > > > > > How do you handle public image updates in your case? > > > > > > > We have a similar problem. For the Horizon based end users, > > we've defined a panel using image meta data. Details are at > > > http://openstack-in-production.blogspot.ch/2015/02/choosing-right-image.html > . > > > > For the CLI users, we propose to use the sort options from > > Glance to find the latest image of a particular OS. > > > > 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. > > > > > Thanks! > > > > > > _______________________________________________ > > > OpenStack-operators mailing list > > > OpenStack-operators@lists.openstack.org <javascript:;> > > > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > _______________________________________________ > > OpenStack-operators mailing list > > OpenStack-operators@lists.openstack.org <javascript:;> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > _______________________________________________ > > OpenStack-operators mailing list > > OpenStack-operators@lists.openstack.org <javascript:;> > > 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
