<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-11-02 16:26 GMT+08:00 Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<br>
<br>
<div class="m_3034761133168338968moz-cite-prefix">Le 01/11/2016 15:14, Alex Xu a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">Currently we only update the resource usage with
Placement API in the instance claim and the available resource
update periodic task. But there is no claim for migration with
placement API yet. This works is tracked by <a href="https://bugs.launchpad.net/nova/+bug/1621709" target="_blank">https://bugs.launchpad.net/<wbr>nova/+bug/1621709</a>.
In newton, we only fix one bit which make the resource update
periodic task works correctly, then it will auto-heal
everything. For the migration claim part, that isn't the goal
for newton release.</div>
</blockquote>
<br></span>
To be clear, there are two distinct points :<br>
#1 there are MoveClaim objects that are synchronously made on resize
(and cold-migrate) and rebuild (and evacuate), but there is no claim
done by the live-migration path.<br>
There is a long-standing bugfix
<a class="m_3034761133168338968moz-txt-link-freetext" href="https://review.openstack.org/#/c/244489/" target="_blank">https://review.openstack.org/#<wbr>/c/244489/</a> that's been tracked by
<a class="m_3034761133168338968moz-txt-link-freetext" href="https://bugs.launchpad.net/nova/+bug/1289064" target="_blank">https://bugs.launchpad.net/<wbr>nova/+bug/1289064</a></div></blockquote><div><br></div><div>Yea, thanks for the info. I say `migration claim` is more about the move claim. Maybe I should say the move claim. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
#2 all those claim operations don't trigger an allocation request to
the placement API, while the regular boot operation does (hence your
bug report).</div></blockquote><div><br></div><div>Yes, except the booting new instance, other claims won't trigger allocation request to the placement API.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span class=""><br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><br>
</div>
<div>So the first question is do we want to fix it in this
release? If the answer is yes, there have a concern need to
discuss.</div>
<div><br>
</div>
</div>
</blockquote>
<br></span>
I'd appreciate if we could merge first #1 before #2 because the
placement API decisions could be wrong if we decide to only allocate
for certain move operations.</div></blockquote><div><br></div><div>Sorry, I didn't get you, what is 'the placement API decisions' pointed to?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span class=""><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>In order to implement the drop of migration claim, the RT
needs to remove allocation records on the specific RP(on the
source/destination compute node). But there isn't any API can
do that. The API about remove allocation records is 'DELETE
/allocations/{consumer_uuid}', but it will delete all the
allocation records for the consumer. So the initial fix(<a href="https://review.openstack.org/#/c/369172/" target="_blank">https://review.openstack.<wbr>org/#/c/369172/</a>)
adds new API '<span style="color:rgb(0,0,0);font-family:monospace;white-space:pre-wrap">DELETE
/resource_providers/{rp_uuid}/<wbr>allocations/{consumer_id}</span>'.
But Chris Dent pointed out this against the original design.
All the allocations for the specific consumer only can be
dropped together.</div>
<div><br>
</div>
<div>There also have suggestion from Andrew, we can update all
the allocation records for the consumer each time. That means
the RT will build the original allocation records and new
allocation records for the claim together, and put into one
API. That API should be 'PUT /allocations/{consumer_uuid}'.
Unfortunately that API doesn't replace all the allocation
records for the consumer, it always amends the new allocation
records for the consumer.</div>
<div><br>
</div>
<div>So which directly we should go at here?</div>
<div><br>
</div>
</div>
</blockquote>
</span><blockquote type="cite">
<div dir="ltr">
<div>Thanks</div>
<div>Alex</div>
<div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<br>
<fieldset class="m_3034761133168338968mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>______________________________<wbr>______________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="m_3034761133168338968moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a>
<a class="m_3034761133168338968moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a>
</pre>
</blockquote>
<br>
</div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div></div>