<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 19, 2018 at 9:59 PM, Artom Lifshitz <span dir="ltr"><<a href="mailto:alifshit@redhat.com" target="_blank">alifshit@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Adding<br>
<span class="gmail-">> claims support later on wouldn't change any on-the-wire messaging, it would<br>
> just make things work more robustly.<br>
<br>
</span>I'm not even sure about that. Assuming [1] has at least the right<br>
idea, it looks like it's an either-or kind of thing: either we use<br>
resource tracker claims and get the new instance NUMA topology that<br>
way, or do what was in the spec and have the dest send it to the<br>
source.<br>
<br>
That being said, I still think I'm still in favor of choosing the<br>
"easy" way out. For instance, [2] should fail because we can't access<br>
the api db from the compute node. So unless there's a simpler way,<br>
using RT claims would involve changing the RPC to add parameters to<br>
check_can_live_migration_<wbr>destination, which, while not necessarily<br>
bad, seems like useless complexity for a thing we know will get ripped<br>
out.<br>
<br></blockquote><div>When we reviewed the spec, we agreed as a community to say that we should still get race conditions once the series is implemented, but at least it helps operators.<br></div><div>Quoting : <br>"It would also be possible for another instance to steal NUMA resources from a
live migrated instance before the latter’s destination compute host has a
chance to claim them. Until NUMA resource providers are implemented <a class="gmail-reference external" href="https://review.openstack.org/#/c/552924/">[3]</a> and
allow for an essentially atomic schedule+claim operation, scheduling and
claiming will keep being done at different times on different nodes. Thus, the
potential for races will continue to exist."<br><a href="https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/numa-aware-live-migration.html#proposed-change">https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/numa-aware-live-migration.html#proposed-change</a><br><br></div><div>So, my own opinion is that yes, the "easy" way out is better than no way. From what I undertand (and let's be honest I hadn't time to look at your code yet), your series don't diverge from the proposed implementation so I don't see a problem here. If, for some reasons, you need to write an alternative, just tell us why (and ideally write a spec amendment patch so the spec is consistent with the series).<br><br></div><div>-Sylvain<br></div><div><br></div><div><br><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[1] <a href="https://review.openstack.org/#/c/576222/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/576222/</a><br>
[2] <a href="https://review.openstack.org/#/c/576222/3/nova/compute/manager.py@5897" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/576222/3/nova/compute/<wbr>manager.py@5897</a><br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><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>
</div></div></blockquote></div><br></div></div>