<div dir="ltr">On 11 October 2015 at 00:23, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm in, except I think this gets simpler with an intermediary service<br>
like ZK/Consul to keep track of this 1GB of data and replace the need<br>
for 6, and changes the implementation of 5 to "updates its record and<br>
signals its presence".<br></blockquote><div><br></div><div>OK, so we're not keeping a copy of the information in the schedulers, saving us 5GB of information, but we are notifying the schedulers of the updated information to that they can update their copies?<br><br></div><div>Also, the notification path here is that the compute host notifies ZK and ZK notifies many schedulers, assuming they're all capable of handling all queries.  That is in fact N * (M+1) messages, which is slightly more than if there's no central node, as it happens.  There are fewer *channels*, but more messages.  (I feel like I'm overlooking something here, but I can't pick out the flaw...)  Yes, RMQ will suck at this - but then let's talk about better messaging rather than another DB type.<br><br></div><div>Again, the saving here seems to be that a freshly started scheduler can get an infodump rather than waiting 60s to be useful.  I wonder if that's necessary.<br>-- <br></div><div>Ian.<br></div></div></div></div>