<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 26, 2013 at 1:53 PM, Soren Hansen <span dir="ltr"><<a href="mailto:soren@linux2go.dk" target="_blank">soren@linux2go.dk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey, sorry for necroposting. I completely missed this thread when it was<br>
active, but Russel just pointed it out to me on Twitter earlier today and<br>
I couldn't help myself.<br>
<br>
<br>
2013/7/19 Sandy Walsh <<a href="mailto:sandy.walsh@rackspace.com">sandy.walsh@rackspace.com</a>>:<br>
<div class="im">> On 07/19/2013 05:01 PM, Boris Pavlovic wrote:<br>
</div><div class="im">> Sorry, I was commenting on Soren's suggestion from way back (essentially<br>
> listening on a separate exchange for each unique flavor ... so no<br>
> scheduler was needed at all). It was a great idea, but fell apart rather<br>
> quickly.<br>
<br>
</div>I don't recall we ever really had the discussion, but it's been a while :)<br>
<br>
Yes, when moving beyond simple flavours, the idea as initially proposed<br>
falls apart. I see two ways to fix that:<br>
<br>
* Don't move beyond simple flavours. Seriously. Amazon have been pretty<br>
darn succesful with just their simple instance types.<br></blockquote><div><br></div><div>Who says we have to support one scheduler model? I can see room for several scheduler models that have different tradeoffs, such as performance / scale vs features/</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* If you must make things complicated, use fanout to send a reservation<br>
request:<br>
<br>
- Send out reservation requests to everyone listening (*)<br>
<br>
- Compute nodes able to accommodate the request reserve the resources<br>
in question and respond directly to the requestor. Those unable to<br>
accommodate the request do nothing.<br>
<br>
- Requestor (scheduler, API server, whatever) picks a winner amongst<br>
the repondants and broadcasts a message announcing the winner of<br>
the request.<br>
<br>
- The winning node acknowledges acceptance of the task to the<br>
requestor and gets to work.<br>
<br>
- Every other node that responded also sees the broadcast and cancels<br>
the reservation.<br>
<br>
- Reservations time out after 5 seconds, so a lost broadcast doesn't<br>
result in reserved-but-never-used resources.<br>
<br>
- If noone has volunteered to accept the reservation request within a<br>
couple of seconds, broadcast wider.<br>
<br>
(*) "Everyone listening" isn't necessarily every node. Maybe you have<br>
topics for nodes that are at less than 10% utilisation, one for less<br>
than 25% utilisation, etc. First broadcast to those at 10% or less, move<br>
on to 20%, etc.<br>
<br>
This is just off the top of my head. I'm sure it can be improved upon. A<br>
lot. My point is just that there's plenty of alternatives to the<br>
omniscient schedulers that we've been used to for 3 years now.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Soren Hansen | <a href="http://linux2go.dk/" target="_blank">http://linux2go.dk/</a><br>
Ubuntu Developer | <a href="http://www.ubuntu.com/" target="_blank">http://www.ubuntu.com/</a><br>
OpenStack Developer | <a href="http://www.openstack.org/" target="_blank">http://www.openstack.org/</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>