Open Stack

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 <klindgren at godaddy.com
> <mailto:klindgren at 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" <clint at fewbar.com
>     <mailto:clint at 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 at lists.openstack.org
>     <mailto: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
>     <mailto: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
>


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