Open Stack

On Thu, 2015-02-05 at 06:39 -0800, Abel Lopez wrote:
> 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. 

Yup, I agree with that. The best approach is probably a tweaked version
of what you proposed: Use a generic name for the latest image and rename
the outdated ones to something like "<image name>-OLD-$date" but don't
make them private. The documentation that you provide to your end users
should clearly tell them to use image names vs UUIDs and to discourage
them from using OLD images. For those that don't read the doc, the
naming alone will discourage bad practices. Some sort of automated motd
with a big fat warning if the image is older than a certain date would
help as well.

> 
> On Thursday, February 5, 2015, Marc Heckmann
> <marc.heckmann at 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.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
>         
>