Open Stack

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.Bell at cern.ch> wrote:
>         > -----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
>         
>         _______________________________________________
>         OpenStack-operators mailing list
>         OpenStack-operators at lists.openstack.org
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators