Open Stack

On 11 October 2015 at 00:23, Clint Byrum <clint at fewbar.com> wrote:

> I'm in, except I think this gets simpler with an intermediary service
> like ZK/Consul to keep track of this 1GB of data and replace the need
> for 6, and changes the implementation of 5 to "updates its record and
> signals its presence".
>

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?

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.

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.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151012/f69e0816/attachment.html>