Open Stack

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 <s>was</s> 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 
> <moreira.belmiro.email.lists at gmail.com 
> <mailto:moreira.belmiro.email.lists at 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
>     <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
>     <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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150206/82b1a35d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_1329313_error_after_migrating_with_deleted_image.patch
Type: text/x-patch
Size: 4064 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150206/82b1a35d/attachment.bin>