<div dir="auto"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As I understand it, Artom is proposing to have a larger race window, essentially <br>
from when the scheduler selects a node until the resource audit runs on that node.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Exactly. When writing the spec I thought we could just call the resource tracker to claim the resources when the migration was done. However, when I started looking at the code in reaction to Sahid's feedback, I noticed that there's no way to do it without the MoveClaim context (right?)</div><div dir="auto"><br></div><div dir="auto">Keep in mind, we're not making any race windows worse - I'm proposing keeping the status quo and fixing it later with NUMA in placement (or the resource tracker if we can swing it).</div><div dir="auto"><br></div><div dir="auto">The resource tracker stuff is just so... opaque. For instance, the original patch [1] uses a mutated_migration_context around the pre_live_migration call to the libvirt driver. Would I still need to do that? Why or why not?</div><div dir="auto"><br></div><div dir="auto">At this point we need to commit to something and roll with it, so I'm sticking to the "easy way". If it gets shut down in code review, at least we'll have certainty on how to approach this next cycle.</div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">[1]</span> <a href="https://review.openstack.org/#/c/244489/" target="_blank" rel="noreferrer">https://review.openstack.org/#/c/244489/</a><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>