<div dir="ltr">Clint, <div><br></div><div>There are many PROS and CONS in both of approaches.</div><div><br></div><div>Reinventing wheel (in this case it's quite simple task) and it gives more flexibility and doesn't require</div><div>usage of ZK/Consul (which will simplify integration of it with current system)</div><div><br></div><div>Using ZK/Consul for POC may save a lot of time and as well we are delegating part of work </div><div>to other communities (which may lead in better supported/working code). </div><div><br></div><div>By the way some of the parts (like sync of schedulers) stuck on review in Nova project. </div><div><br></div><div>Basically for POC we can use anything and using ZK/Consul may reduce resources for development</div><div>which is good. </div><div><br></div><div>Best regards,</div><div>Boris Pavlovic </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 11, 2015 at 12:23 AM, Clint Byrum <span dir="ltr"><<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Boris Pavlovic's message of 2015-10-11 00:02:39 -0700:<br>
<div><div class="h5">> 2Everybody,<br>
><br>
> Just curios why we need such complexity.<br>
><br>
><br>
> Let's take a look from other side:<br>
> 1) Information about all hosts (even in case of 100k hosts) will be less<br>
> then 1 GB<br>
> 2) Usually servers that runs scheduler service have at least 64GB RAM and<br>
> more on the board<br>
> 3) math.log(100000) < 12  (binary search per rule)<br>
> 4) We have less then 20 rules for scheduling<br>
> 5) Information about hosts is updated every 60 seconds (no updates host is<br>
> dead)<br>
><br>
><br>
> According to this information:<br>
> 1) We can store everything in RAM of single server<br>
> 2) We can use Python<br>
> 3) Information about hosts is temporary data and shouldn't be stored in<br>
> persistence storage<br>
><br>
><br>
> Simplest architecture to cover this:<br>
> 1) Single RPC service that has two methods: find_host(rules),<br>
> update_host(host, data)<br>
> 2) Store information about hosts  like a dict (host_name->data)<br>
> 3) Create for each rule binary tree and update it on each host update<br>
> 4) Make a algorithm that will use binary trees to find host based on rules<br>
> 5) Each service like compute node, volume node, or neutron will send<br>
> updates about host<br>
>    that they managed (cross service scheduling)<br>
> 6) Make a algorithm that will sync host stats in memory between different<br>
> schedulers<br>
<br>
</div></div>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>
<br>
What you've described is where I'd like to experiment, but I don't want<br>
to reinvent ZK or Consul or etcd when they already exist and do such a<br>
splendid job keeping observers informed of small changes in small data<br>
sets. You still end up with the same in-memory performance, and this is<br>
in line with some published white papers from Google around their use<br>
of Chubby, which is their ZK/Consul.<br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>