> -----Original Message----- > From: George Shuklin [mailto:[email protected]] > Sent: 05 February 2015 14:10 > To: [email protected] > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
