Re: [Openstack-operators] How to handle updates of public images?

[Igor Bolotin]

I'm not sure making image private or downgrading to community sharing is
the right concept for this.

I agree with community sharing. I think being able to distinguish between
public officially supported provider images and public, but not supported
by cloud provider is definitely needed.

However - retiring/hiding/archiving/deactivating (pick your term) outdated
public or community image (especially when it has known vulnerabilities) -
is part of managing image life-cycle vs. image sharing that
public/private/shared/community addresses.

There is another bp that seem to be very similar to this idea, but it
focused on disabling download rather than hiding image:
https://review.openstack.org/#/c/132717/

Best regards,
Igor


On Sat, Feb 7, 2015 at 12:35 PM, Louis Taylor  wrote:

> On Sat, Feb 07, 2015 at 10:36:55AM -0800, Igor Bolotin wrote:
> > Going back to the idea of archiving images and not allowing launch of new
> > VMs and hiding archived images by default in Horizon/CLI (maybe still can
> > list/show if requested, possibly admin function only). Would it make
> sense
> > to propose this as a blueprint for the next release?
>
> There is currently a spec under review [1] for a new type of image which
> covers
> some of the usecases in this thread. Momentumn has fallen off on working
> on it,
> but with a little luck it should be in the Kilo release. Further comments
> and
> feedback on that spec may be helpful in moving it along and getting it
> ready in
> time.
>
> The basic idea is that the old images are moved from being public images to
> 'community' images, which remain bootable, but not visible in normal user
> listings.
>
> Louis
>
> [1] https://review.openstack.org/#/c/124050/11
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>


-- 
Best regards,
Igor
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How to handle updates of public images?

[George Shuklin]

On 02/07/2015 08:36 PM, Igor Bolotin wrote:
Going back to the idea of archiving images and not allowing launch of 
new VMs and hiding archived images by default in Horizon/CLI (maybe 
still can list/show if requested, possibly admin function only). Would 
it make sense to propose this as a blueprint for the next release?



Yes, it sounds nice.

But more important - I want to have '_base' gone away when raw disks are 
used in nova. Why it's needed?



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] How to handle updates of public images?

[Louis Taylor]

On Sat, Feb 07, 2015 at 10:36:55AM -0800, Igor Bolotin wrote:
> Going back to the idea of archiving images and not allowing launch of new
> VMs and hiding archived images by default in Horizon/CLI (maybe still can
> list/show if requested, possibly admin function only). Would it make sense
> to propose this as a blueprint for the next release?

There is currently a spec under review [1] for a new type of image which covers
some of the usecases in this thread. Momentumn has fallen off on working on it,
but with a little luck it should be in the Kilo release. Further comments and
feedback on that spec may be helpful in moving it along and getting it ready in
time.

The basic idea is that the old images are moved from being public images to
'community' images, which remain bootable, but not visible in normal user
listings.

Louis

[1] https://review.openstack.org/#/c/124050/11


signature.asc
Description: Digital signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How to handle updates of public images?

[Abel Lopez]

You can achieve this by simply making the image as private "--is-public 0"

You have it in the admin tenant, and can use member to share it if needed.

On Saturday, February 7, 2015, Igor Bolotin 
wrote:

> Going back to the idea of archiving images and not allowing launch of new
> VMs and hiding archived images by default in Horizon/CLI (maybe still can
> list/show if requested, possibly admin function only). Would it make sense
> to propose this as a blueprint for the next release?
>
> Best regards,
> Igor
>
> On Thu, Feb 5, 2015 at 5:34 AM, Tim Bell  > wrote:
>
>> > -Original Message-
>> > From: George Shuklin [mailto:george.shuk...@gmail.com
>> ]
>> > Sent: 05 February 2015 14:10
>> > To: openstack-operators@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@lists.openstack.org
>> 
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
>
> --
> Best regards,
> Igor
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How to handle updates of public images?

[Tim Bell]

I’d be in favour of this as there are also other use cases where we want to 
avoid images being used but still want to continue the use of Glance images 
when there is no need for new images.

Something which would hide, by default, an image from both glance image list 
and GUIs but allow a ‘show all’ option if needed would be very useful.

I think the implementation would not be too complex too.

Tim

From: Igor Bolotin [mailto:igor_bolo...@symantec40.com]
Sent: 07 February 2015 19:37
To: Tim Bell
Cc: George Shuklin; openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] How to handle updates of public images?

Going back to the idea of archiving images and not allowing launch of new VMs 
and hiding archived images by default in Horizon/CLI (maybe still can list/show 
if requested, possibly admin function only). Would it make sense to propose 
this as a blueprint for the next release?
Best regards,
Igor

On Thu, Feb 5, 2015 at 5:34 AM, Tim Bell 
mailto:tim.b...@cern.ch>> wrote:
> -Original Message-
> From: George Shuklin 
> [mailto:george.shuk...@gmail.com<mailto:george.shuk...@gmail.com>]
> Sent: 05 February 2015 14:10
> To: 
> openstack-operators@lists.openstack.org<mailto:openstack-operators@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@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org<mailto:OpenStack-operators@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



--
Best regards,
Igor
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How to handle updates of public images?

[Igor Bolotin]

Going back to the idea of archiving images and not allowing launch of new
VMs and hiding archived images by default in Horizon/CLI (maybe still can
list/show if requested, possibly admin function only). Would it make sense
to propose this as a blueprint for the next release?

Best regards,
Igor

On Thu, Feb 5, 2015 at 5:34 AM, Tim Bell  wrote:

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



-- 
Best regards,
Igor
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How to handle updates of public images?

[George Shuklin]

Hello. We're forced to use _base because nova wants them. But disks are 
raw and _base is just overhead.


Migration (we use cold migration with instance shutdown) with deleted 
images was is broken in havana, but we're using patch from 
icehouse (see attachment and 
https://bugs.launchpad.net/nova/+bug/1329313). I still didn't test it 
with juno (in process).


On 02/06/2015 12:11 AM, Joe Topjian wrote:
I'm curious: are you using _base files? We're not and we're able to 
block migrate instances based on deleted images or images that were 
public but are now private.


On Thu, Feb 5, 2015 at 2:42 PM, Belmiro Moreira 
> wrote:


We don't delete public images from Glance because it breaks
migrate/resize and block live migration. Not tested with upstream
Kilo, though.
As consequence, our public image list has been growing over time...

In order to manage image releases we use "glance image properties"
to tag them.

Some relevant reviews:
https://review.openstack.org/#/c/150337/
https://review.openstack.org/#/c/90321/

Belmiro
CERN

On Thu, Feb 5, 2015 at 8:16 PM, Kris G. Lindgren
mailto:klindg...@godaddy.com>> wrote:

In the case of a raw backed qcow2 image (pretty sure that¹s
the default)
the instances root disk as seen inside the vm is made up of
changes made
on the instance disk (qcow2 layer) + the base image (raw). 
Also, remember

that as currently coded a resize migration will almost always be a
migrate.  However, since the vm is successfully running on the
old compute
node it *should* be a trivial change that if the backing image
is no
longer available via glance - copy that over to the new host
as well.


Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.




On 2/5/15, 11:55 AM, "Clint Byrum" mailto:cl...@fewbar.com>> wrote:

>Excerpts from George Shuklin's message of 2015-02-05 05:09:51
-0800:
>> 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)
>>
>
>Some thoughts:
>
>* All of the operations described should be operating on an
image ID. So
>the other suggestions of renaming seems the right way to go.
"Ubuntu
>14.04" becomes "Ubuntu 14.04 02052015" and the ID remains in
the system
>for a while. If something inside Nova doesn't work with IDs,
it seems
>like a bug.
>
>* rebuild, revert, rescue, and resize, are all very _not_
cloud things
>that increase the complexity of Nova. Perhaps we should all
reconsider
>their usefulness and encourage our users to spin up new
resources, use
>volumes and/or backup/restore methods, and then tear down old
instances.
>
>One way to encourage them is to make it clear that these
operations will
>only work for X amount of time before old versions images
will be removed.
>So if you spin up Ubuntu 14.04 today, reverts and resizes and
rescues
>are only guaranteed to work for 6 months. Then aggressively
clean up >
>6 month old image ids. To make this practical, you might even
require
>a role, something like "reverter", "rescuer", "resizer" and
only allow
>those roles to do these operations, and then before purging
images,
>notify those users in those roles of instances they won't be
able to
>resize/rescue/revert anymore.
>
>It also makes no sense to me why migrating an instance
requires its
>original image. The instance root disk is all that should matter.
>
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org

>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-opera

Re: [Openstack-operators] How to handle updates of public images?

[Masahito MUROI]

We're using image member to share images instead of public images 
because we can share different images with same name for others, and 
when updating images we replace members of the existing image to new 
one. Then, we delete the old image when all vms using it are deleted on 
hypervisors.


This operation doesn't increase public image list.

Masa

On 2015/02/06 6:42, Belmiro Moreira wrote:

We don't delete public images from Glance because it breaks
migrate/resize and block live migration. Not tested with upstream Kilo,
though.
As consequence, our public image list has been growing over time...

In order to manage image releases we use "glance image properties" to
tag them.

Some relevant reviews:
https://review.openstack.org/#/c/150337/
https://review.openstack.org/#/c/90321/

Belmiro
CERN

On Thu, Feb 5, 2015 at 8:16 PM, Kris G. Lindgren mailto:klindg...@godaddy.com>> wrote:

In the case of a raw backed qcow2 image (pretty sure that¹s the default)
the instances root disk as seen inside the vm is made up of changes made
on the instance disk (qcow2 layer) + the base image (raw).  Also,
remember
that as currently coded a resize migration will almost always be a
migrate.  However, since the vm is successfully running on the old
compute
node it *should* be a trivial change that if the backing image is no
longer available via glance - copy that over to the new host as well.


Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.




On 2/5/15, 11:55 AM, "Clint Byrum" mailto:cl...@fewbar.com>> wrote:

 >Excerpts from George Shuklin's message of 2015-02-05 05:09:51 -0800:
 >> 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)
 >>
 >
 >Some thoughts:
 >
 >* All of the operations described should be operating on an image
ID. So
 >the other suggestions of renaming seems the right way to go. "Ubuntu
 >14.04" becomes "Ubuntu 14.04 02052015" and the ID remains in the
system
 >for a while. If something inside Nova doesn't work with IDs, it seems
 >like a bug.
 >
 >* rebuild, revert, rescue, and resize, are all very _not_ cloud things
 >that increase the complexity of Nova. Perhaps we should all reconsider
 >their usefulness and encourage our users to spin up new resources, use
 >volumes and/or backup/restore methods, and then tear down old
instances.
 >
 >One way to encourage them is to make it clear that these
operations will
 >only work for X amount of time before old versions images will be
removed.
 >So if you spin up Ubuntu 14.04 today, reverts and resizes and rescues
 >are only guaranteed to work for 6 months. Then aggressively clean up >
 >6 month old image ids. To make this practical, you might even require
 >a role, something like "reverter", "rescuer", "resizer" and only allow
 >those roles to do these operations, and then before purging images,
 >notify those users in those roles of instances they won't be able to
 >resize/rescue/revert anymore.
 >
 >It also makes no sense to me why migrating an instance requires its
 >original image. The instance root disk is all that should matter.
 >
 >___
 >OpenStack-operators mailing list
 >OpenStack-operators@lists.openstack.org

 >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators




--
室井 雅仁(Masahito MUROI)
Software Innovation Center, NTT
Tel: +81-422-59-4539，FAX: +81-422-59-2699


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How to handle updates of public images?

[Joe Topjian]

I'm curious: are you using _base files? We're not and we're able to block
migrate instances based on deleted images or images that were public but
are now private.

On Thu, Feb 5, 2015 at 2:42 PM, Belmiro Moreira <
moreira.belmiro.email.li...@gmail.com> wrote:

> We don't delete public images from Glance because it breaks migrate/resize
> and block live migration. Not tested with upstream Kilo, though.
> As consequence, our public image list has been growing over time...
>
> In order to manage image releases we use "glance image properties" to tag
> them.
>
> Some relevant reviews:
> https://review.openstack.org/#/c/150337/
> https://review.openstack.org/#/c/90321/
>
> Belmiro
> CERN
>
> On Thu, Feb 5, 2015 at 8:16 PM, Kris G. Lindgren 
> wrote:
>
>> In the case of a raw backed qcow2 image (pretty sure that¹s the default)
>> the instances root disk as seen inside the vm is made up of changes made
>> on the instance disk (qcow2 layer) + the base image (raw).  Also, remember
>> that as currently coded a resize migration will almost always be a
>> migrate.  However, since the vm is successfully running on the old compute
>> node it *should* be a trivial change that if the backing image is no
>> longer available via glance - copy that over to the new host as well.
>> 
>>
>> Kris Lindgren
>> Senior Linux Systems Engineer
>> GoDaddy, LLC.
>>
>>
>>
>>
>> On 2/5/15, 11:55 AM, "Clint Byrum"  wrote:
>>
>> >Excerpts from George Shuklin's message of 2015-02-05 05:09:51 -0800:
>> >> 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)
>> >>
>> >
>> >Some thoughts:
>> >
>> >* All of the operations described should be operating on an image ID. So
>> >the other suggestions of renaming seems the right way to go. "Ubuntu
>> >14.04" becomes "Ubuntu 14.04 02052015" and the ID remains in the system
>> >for a while. If something inside Nova doesn't work with IDs, it seems
>> >like a bug.
>> >
>> >* rebuild, revert, rescue, and resize, are all very _not_ cloud things
>> >that increase the complexity of Nova. Perhaps we should all reconsider
>> >their usefulness and encourage our users to spin up new resources, use
>> >volumes and/or backup/restore methods, and then tear down old instances.
>> >
>> >One way to encourage them is to make it clear that these operations will
>> >only work for X amount of time before old versions images will be
>> removed.
>> >So if you spin up Ubuntu 14.04 today, reverts and resizes and rescues
>> >are only guaranteed to work for 6 months. Then aggressively clean up >
>> >6 month old image ids. To make this practical, you might even require
>> >a role, something like "reverter", "rescuer", "resizer" and only allow
>> >those roles to do these operations, and then before purging images,
>> >notify those users in those roles of instances they won't be able to
>> >resize/rescue/revert anymore.
>> >
>> >It also makes no sense to me why migrating an instance requires its
>> >original image. The instance root disk is all that should matter.
>> >
>> >___
>> >OpenStack-operators mailing list
>> >OpenStack-operators@lists.openstack.org
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How to handle updates of public images?

[Belmiro Moreira]

We don't delete public images from Glance because it breaks migrate/resize
and block live migration. Not tested with upstream Kilo, though.
As consequence, our public image list has been growing over time...

In order to manage image releases we use "glance image properties" to tag
them.

Some relevant reviews:
https://review.openstack.org/#/c/150337/
https://review.openstack.org/#/c/90321/

Belmiro
CERN

On Thu, Feb 5, 2015 at 8:16 PM, Kris G. Lindgren 
wrote:

> In the case of a raw backed qcow2 image (pretty sure that¹s the default)
> the instances root disk as seen inside the vm is made up of changes made
> on the instance disk (qcow2 layer) + the base image (raw).  Also, remember
> that as currently coded a resize migration will almost always be a
> migrate.  However, since the vm is successfully running on the old compute
> node it *should* be a trivial change that if the backing image is no
> longer available via glance - copy that over to the new host as well.
> 
>
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy, LLC.
>
>
>
>
> On 2/5/15, 11:55 AM, "Clint Byrum"  wrote:
>
> >Excerpts from George Shuklin's message of 2015-02-05 05:09:51 -0800:
> >> 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)
> >>
> >
> >Some thoughts:
> >
> >* All of the operations described should be operating on an image ID. So
> >the other suggestions of renaming seems the right way to go. "Ubuntu
> >14.04" becomes "Ubuntu 14.04 02052015" and the ID remains in the system
> >for a while. If something inside Nova doesn't work with IDs, it seems
> >like a bug.
> >
> >* rebuild, revert, rescue, and resize, are all very _not_ cloud things
> >that increase the complexity of Nova. Perhaps we should all reconsider
> >their usefulness and encourage our users to spin up new resources, use
> >volumes and/or backup/restore methods, and then tear down old instances.
> >
> >One way to encourage them is to make it clear that these operations will
> >only work for X amount of time before old versions images will be removed.
> >So if you spin up Ubuntu 14.04 today, reverts and resizes and rescues
> >are only guaranteed to work for 6 months. Then aggressively clean up >
> >6 month old image ids. To make this practical, you might even require
> >a role, something like "reverter", "rescuer", "resizer" and only allow
> >those roles to do these operations, and then before purging images,
> >notify those users in those roles of instances they won't be able to
> >resize/rescue/revert anymore.
> >
> >It also makes no sense to me why migrating an instance requires its
> >original image. The instance root disk is all that should matter.
> >
> >___
> >OpenStack-operators mailing list
> >OpenStack-operators@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How to handle updates of public images?

[Kris G. Lindgren]

In the case of a raw backed qcow2 image (pretty sure that¹s the default)
the instances root disk as seen inside the vm is made up of changes made
on the instance disk (qcow2 layer) + the base image (raw).  Also, remember
that as currently coded a resize migration will almost always be a
migrate.  However, since the vm is successfully running on the old compute
node it *should* be a trivial change that if the backing image is no
longer available via glance - copy that over to the new host as well.

 
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.




On 2/5/15, 11:55 AM, "Clint Byrum"  wrote:

>Excerpts from George Shuklin's message of 2015-02-05 05:09:51 -0800:
>> 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)
>> 
>
>Some thoughts:
>
>* All of the operations described should be operating on an image ID. So
>the other suggestions of renaming seems the right way to go. "Ubuntu
>14.04" becomes "Ubuntu 14.04 02052015" and the ID remains in the system
>for a while. If something inside Nova doesn't work with IDs, it seems
>like a bug.
>
>* rebuild, revert, rescue, and resize, are all very _not_ cloud things
>that increase the complexity of Nova. Perhaps we should all reconsider
>their usefulness and encourage our users to spin up new resources, use
>volumes and/or backup/restore methods, and then tear down old instances.
>
>One way to encourage them is to make it clear that these operations will
>only work for X amount of time before old versions images will be removed.
>So if you spin up Ubuntu 14.04 today, reverts and resizes and rescues
>are only guaranteed to work for 6 months. Then aggressively clean up >
>6 month old image ids. To make this practical, you might even require
>a role, something like "reverter", "rescuer", "resizer" and only allow
>those roles to do these operations, and then before purging images,
>notify those users in those roles of instances they won't be able to
>resize/rescue/revert anymore.
>
>It also makes no sense to me why migrating an instance requires its
>original image. The instance root disk is all that should matter.
>
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How to handle updates of public images?

[Clint Byrum]

Excerpts from George Shuklin's message of 2015-02-05 05:09:51 -0800:
> 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)
> 

Some thoughts:

* All of the operations described should be operating on an image ID. So
the other suggestions of renaming seems the right way to go. "Ubuntu
14.04" becomes "Ubuntu 14.04 02052015" and the ID remains in the system
for a while. If something inside Nova doesn't work with IDs, it seems
like a bug.

* rebuild, revert, rescue, and resize, are all very _not_ cloud things
that increase the complexity of Nova. Perhaps we should all reconsider
their usefulness and encourage our users to spin up new resources, use
volumes and/or backup/restore methods, and then tear down old instances.

One way to encourage them is to make it clear that these operations will
only work for X amount of time before old versions images will be removed.
So if you spin up Ubuntu 14.04 today, reverts and resizes and rescues
are only guaranteed to work for 6 months. Then aggressively clean up >
6 month old image ids. To make this practical, you might even require
a role, something like "reverter", "rescuer", "resizer" and only allow
those roles to do these operations, and then before purging images,
notify those users in those roles of instances they won't be able to
resize/rescue/revert anymore.

It also makes no sense to me why migrating an instance requires its
original image. The instance root disk is all that should matter.

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How to handle updates of public images?

[matt]

kinda tempted to suggest using some sort of like NSA project code name
generator.   Keeps it short, memorable, and unique.

Example Possible Image Names:

Lackluster Aardvark
Screaming Potato
Languid Porpoise

On Thu, Feb 5, 2015 at 10:45 AM, George Shuklin 
wrote:

> Updated report for 'no image' with deleted '_base' behaviour in juno (my
> previous comment was about havana):
>
> 1. If snapshot is removed, original image is used (image that was used for
> 1st instance to produce snapshot). Rather strange and unexpected, but nice
> (minus one headache).
> 2. If all images in chain are removed, behaviour changed:
> * hard reboot works fine (raw disks)
> * reinstallation asks for new image, seems no problem
> * rescue causes ugly problem, rendering instance completely broken (do not
> work but no ERROR state). https://bugs.launchpad.net/nova/+bug/1418590
>
> I didn't test migrations yet.
>
>
> On 02/05/2015 03:09 PM, George Shuklin wrote:
>
>> 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?
>>
>> Thanks!
>>
>
>
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How to handle updates of public images?

[George Shuklin]

Updated report for 'no image' with deleted '_base' behaviour in juno (my 
previous comment was about havana):


1. If snapshot is removed, original image is used (image that was used 
for 1st instance to produce snapshot). Rather strange and unexpected, 
but nice (minus one headache).

2. If all images in chain are removed, behaviour changed:
* hard reboot works fine (raw disks)
* reinstallation asks for new image, seems no problem
* rescue causes ugly problem, rendering instance completely broken (do 
not work but no ERROR state). https://bugs.launchpad.net/nova/+bug/1418590


I didn't test migrations yet.

On 02/05/2015 03:09 PM, George Shuklin wrote:

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?

Thanks!



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How to handle updates of public images?

[Joe Topjian]

We do exactly this.

Public images are named very generically like "Ubuntu 14.04". Not even
"14.04.1" or something like that. Old images are renamed and made private.
Existing instances continue to run, but, as others have mentioned, if a
user is using a  UUID to launch instances, that will break for them. This
is an acceptable trade-offf or us. Our documentation makes mention of this
and to use the names.

The OpenStack CLI tools as well as Vagrant (the two most used non-Dashboard
tools that are used) both support image names, so we haven't run into a
UUID-only issue.

We have a modified MOTD that lists some different scripts that the user can
run, such as:

* Using our local apt-cache server (Ubuntu only)
* Enabling automatic updates
* Install the openstack command-line tools

We had a few debates about turning on automatic updates in the images we
provide. Ultimately we chose to not enable them and instead go with the
MOTD message. There are several reasons why having automatic updates
enabled is a benefit, but the single reason that made us not do it is
simply "if an automatic update breaks the user's instance, it's our fault."
It's a very debatable argument.

Also, we use Packer to bundle all of this. We have most of it available
here:

https://github.com/cybera/openstack-images

In addition to all of this, we allow users to upload their own images. So
if the core set of images we provide doesn't meet their needs, they're free
to do create their own solution.

On Thu, Feb 5, 2015 at 7:02 AM, 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.
>
> We're discussing baking the images with automatic updates, but still
> haven't reached an agreement.
>
>
> On Thursday, February 5, 2015, Tim Bell  wrote:
>
>> > -Original Message-
>> > From: George Shuklin [mailto:george.shuk...@gmail.com]
>> > Sent: 05 February 2015 14:10
>> > To: openstack-operators@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@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/l

Re: [Openstack-operators] How to handle updates of public images?

[Marc Heckmann]

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 "-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
>  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 
> wrote:
> > > -Original Message-
> >     > From: George Shuklin
> [mailto:george.shuk...@gmail.com]
> > > Sent: 05 February 2015 14:10
> > > To: openstack-operators@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
> >   

Re: [Openstack-operators] How to handle updates of public images?

[Abel Lopez]

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

Re: [Openstack-operators] How to handle updates of public images?

[Marc Heckmann]

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


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] How to handle updates of public images?

[Abel Lopez]

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.

We're discussing baking the images with automatic updates, but still
haven't reached an agreement.

On Thursday, February 5, 2015, Tim Bell  wrote:

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

Re: [Openstack-operators] How to handle updates of public images?

[Tim Bell]

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

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] How to handle updates of public images?

[George Shuklin]

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?

Thanks!

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators