<div dir="ltr">Hi Chris,<div><br><div><div class="gmail_extra"><br><div class="gmail_quote">2014-03-18 0:36 GMT+01:00 Chris Friesen <span dir="ltr"><<a href="mailto:chris.friesen@windriver.com" target="_blank">chris.friesen@windriver.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On 03/17/2014 05:01 PM, Sylvain Bauza wrote:<br>

<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
There are 2 distinct cases :<br>
1. there are multiple schedulers involved in the decision<br>
2. there is one single scheduler but there is a race condition on it<br>
</blockquote>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
About 1., I agree we need to see how the scheduler (and later on Gantt)<br>
could address decision-making based on distributed engines. At least, I<br>
consider the no-db scheduler blueprint responsible for using memcache<br>
instead of a relational DB could help some of these issues, as memcached<br>
can be distributed efficiently.<br>
</blockquote>
<br></div>
With a central database we could do a single atomic transaction that looks something like "select the first host A from list of hosts L that is not in the list of hosts used by servers in group G and then set the host field for server S to A".  In that context simultaneous updates can't happen because they're serialized by the central database.<br>

<br>
How would one handle the above for simultaneous scheduling operations without a centralized data store?  (I've never played with memcached, so I'm not really familiar with what it can do.)<div class=""><br></div>
</blockquote><div><br></div><div>See the rationale here for memcached-based scheduler : <a href="https://blueprints.launchpad.net/nova/+spec/no-db-scheduler">https://blueprints.launchpad.net/nova/+spec/no-db-scheduler</a></div>
<div>The idea is to leverage the capabilities of distributed memcached servers with synchronization so that the decision would be scalable. As said in the blueprint, another way would be to make use of RPC fanouts, but that's something Openstack in general tries to avoid.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
About 2., that's a concurrency issue which can be addressed thanks to<br>
common practices for synchronizing actions. IMHO, a local lock can be<br>
enough for ensuring isolation<br>
</blockquote>
<br></div>
It's not that simple though.  Currently the scheduler makes a decision, but the results of that decision aren't actually kept in the scheduler or written back to the db until much later when the instance is actually spawned on the compute node.  So when the next scheduler request comes in we violate the scheduling policy.  Local locking wouldn't help this.<div class="">
<div class="h5"><br>
<br></div></div></blockquote><div><br></div><div>Uh, you're right, missed that crucial point. That said, we should consider that as a classlcal problem of placement with deferral action. One possibility would be to consider that the host is locked to this group at the scheduling decision time, even if the first instance hasn't yet booted. Consider it as a "cache" with TTL if you wish. Thus, that implies the scheduler would need to have a feedback value from the compute node saying that the instance really booted. If no ACK comes from the compute node, once the TTL vanishes, the lock is freed.</div>
<div><br></div><div>-Sylvain</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">
Chris<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div></div>