Open Stack

> -----Original Message-----
> From: George Shuklin [mailto:george.shuklin at gmail.com]
> Sent: 05 February 2015 14:10
> To: openstack-operators at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators