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> wrote: > > -----Original Message----- > > From: George Shuklin [mailto:george.shuk...@gmail.com] > > Sent: 05 February 2015 14:10 > > To: openstack-operators@lists.openstack.org > > 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 > > > > 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 > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > 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