Open Stack

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> 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>
> 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> 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
>> >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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150205/888b6a74/attachment.html>