Open Stack

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.

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 <javascript:;>>
> wrote:
> >         > -----Original Message-----
> >         > From: George Shuklin [mailto:george.shuklin at gmail.com
> <javascript:;>]
> >         > Sent: 05 February 2015 14:10
> >         > To: openstack-operators at lists.openstack.org <javascript:;>
> >         > 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 <javascript:;>
> >         >
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> >         _______________________________________________
> >         OpenStack-operators mailing list
> >         OpenStack-operators at lists.openstack.org <javascript:;>
> >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org <javascript:;>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150205/7cfabc0a/attachment.html>