<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix"><br>
Hello. We're forced to use _base because nova wants them. But
disks are raw and _base is just overhead.<br>
<br>
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
<a class="moz-txt-link-freetext" href="https://bugs.launchpad.net/nova/+bug/1329313">https://bugs.launchpad.net/nova/+bug/1329313</a>). I still didn't test
it with juno (in process).<br>
<br>
On 02/06/2015 12:11 AM, Joe Topjian wrote:<br>
</div>
<blockquote
cite="mid:CA+y7hvhd=upH5xA+smeKouMnkdG9wjdhvHnk53jNq7hWJ-28Ag@mail.gmail.com"
type="cite">
<div dir="ltr">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.</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Feb 5, 2015 at 2:42 PM, Belmiro
Moreira <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:moreira.belmiro.email.lists@gmail.com"
target="_blank">moreira.belmiro.email.lists@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>We don't delete public images from Glance because it
breaks migrate/resize and block live migration. Not
tested with upstream Kilo, though.</div>
<div>As consequence, our public image list has been
growing over time...</div>
<div><br>
</div>
<div>In order to manage image releases we use "glance
image properties" to tag them.<br>
</div>
<div><br>
</div>
<div>Some relevant reviews:</div>
<div><a moz-do-not-send="true"
href="https://review.openstack.org/#/c/150337/"
target="_blank">https://review.openstack.org/#/c/150337/</a><br>
</div>
<div><a moz-do-not-send="true"
href="https://review.openstack.org/#/c/90321/"
target="_blank">https://review.openstack.org/#/c/90321/</a><br>
</div>
<div><br>
</div>
<div>
<div>Belmiro</div>
<div>CERN</div>
</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Feb 5, 2015 at 8:16
PM, Kris G. Lindgren <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:klindgren@godaddy.com"
target="_blank">klindgren@godaddy.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">In
the case of a raw backed qcow2 image (pretty sure
thatıs the default)<br>
the instances root disk as seen inside the vm is
made up of changes made<br>
on the instance disk (qcow2 layer) + the base
image (raw). Also, remember<br>
that as currently coded a resize migration will
almost always be a<br>
migrate. However, since the vm is successfully
running on the old compute<br>
node it *should* be a trivial change that if the
backing image is no<br>
longer available via glance - copy that over to
the new host as well.<br>
____________________________________________<br>
<br>
Kris Lindgren<br>
Senior Linux Systems Engineer<br>
GoDaddy, LLC.<br>
<div>
<div><br>
<br>
<br>
<br>
On 2/5/15, 11:55 AM, "Clint Byrum" <<a
moz-do-not-send="true"
href="mailto:clint@fewbar.com"
target="_blank">clint@fewbar.com</a>>
wrote:<br>
<br>
>Excerpts from George Shuklin's message of
2015-02-05 05:09:51 -0800:<br>
>> Hello everyone.<br>
>><br>
>> We are updating our public images
regularly (to provide them to<br>
>> customers in up-to-date state). But
there is a problem: If some<br>
>>instance<br>
>> starts from image it becomes 'used'.
That means:<br>
>> * That image is used as _base for
nova<br>
>> * If instance is reverted this image
is used to recreate instance's disk<br>
>> * If instance is rescued this image
is used as rescue base<br>
>> * It is redownloaded during
resize/migration (on a new compute node)<br>
>><br>
><br>
>Some thoughts:<br>
><br>
>* All of the operations described should
be operating on an image ID. So<br>
>the other suggestions of renaming seems
the right way to go. "Ubuntu<br>
>14.04" becomes "Ubuntu 14.04 02052015" and
the ID remains in the system<br>
>for a while. If something inside Nova
doesn't work with IDs, it seems<br>
>like a bug.<br>
><br>
>* rebuild, revert, rescue, and resize, are
all very _not_ cloud things<br>
>that increase the complexity of Nova.
Perhaps we should all reconsider<br>
>their usefulness and encourage our users
to spin up new resources, use<br>
>volumes and/or backup/restore methods, and
then tear down old instances.<br>
><br>
>One way to encourage them is to make it
clear that these operations will<br>
>only work for X amount of time before old
versions images will be removed.<br>
>So if you spin up Ubuntu 14.04 today,
reverts and resizes and rescues<br>
>are only guaranteed to work for 6 months.
Then aggressively clean up ><br>
>6 month old image ids. To make this
practical, you might even require<br>
>a role, something like "reverter",
"rescuer", "resizer" and only allow<br>
>those roles to do these operations, and
then before purging images,<br>
>notify those users in those roles of
instances they won't be able to<br>
>resize/rescue/revert anymore.<br>
><br>
>It also makes no sense to me why migrating
an instance requires its<br>
>original image. The instance root disk is
all that should matter.<br>
><br>
>_______________________________________________<br>
>OpenStack-operators mailing list<br>
><a moz-do-not-send="true"
href="mailto:OpenStack-operators@lists.openstack.org"
target="_blank">OpenStack-operators@lists.openstack.org</a><br>
><a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-operators@lists.openstack.org"
target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a moz-do-not-send="true"
href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators"
target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-operators mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a>
</pre>
</blockquote>
<br>
</body>
</html>