<br><br><div class="gmail_quote">On Tue, May 22, 2012 at 11:02 AM, Eric Windisch <span dir="ltr"><<a href="mailto:eric@cloudscaling.com" target="_blank">eric@cloudscaling.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><span style="font-size:12px">Bringing my conversation with Doug back on-list...</span></div><div><span style="font-size:12px"><br></span></div><div></div><blockquote type="cite" style="border-left-style:solid;border-left-color:rgb(0,33,98);color:rgb(0,33,98);border-top-width:1px;border-right-width:1px;border-bottom-width:1px;border-left-width:1px;margin-left:0px;padding-left:10px;padding-right:0px;margin-right:0px">
<div>In nova.rpc with fanout=True every consumer gets a copy of the event because every consumer has its own queue. With fanout=False only one consumer *at all* will get a copy of the event, since they all listen on the same queue. The changes I made come somewhere in between that. It allows multiple consumers to receive a given message, but it also allows several consumers to declare that they are collaborating so that only one of the subset receives a copy. That means that multiple types of consumers can be listening to notifications (metering and audit logging, for example) and each type of consumer can have a load balanced pool of workers so that messages are only processed once for metering and once for logging.</div>
<div></div></blockquote><div><span style="font-size:12px">We can do this today with the Matchmaker. You can use a standard fanout, but make one of the hosts a DNS entry with multiple A or CNAME records for round-robin DNS, where that "host" will act as a pool of workers.  It would be trivial to update the matchmaker to support nested lists to support this with IP addresses as well, doing round-robin or random-selection of hosts without a pool of workers.</span></div>
</blockquote><div><br></div><div>That sounds like a lot like a traditional load-balancing approach.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><span style="font-size:12px">Unfortunately, doing this in the AMQP fashion of registering workers is difficult to do via the matchmaker. Not impossible, but it requires that the matchmakers have a (de)centralized datastore. This could be solved by having get_workers and/or create_consumer communicate to the matchmaker and update mysql, zookeeper, redis, etc.  While I think this is a viable approach, I've avoided /requiring/ this paradigm as the alternatives of using hash maps and/or DNS are significantly less complex and easier to scale and keep available.</span> </div>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span style="font-size:12px"><br></span></div><div><span style="font-size:12px">We should consider to what degree dynamic vs static configuration is necessary, if dynamic is truly required, and how a method like get_workers should behave on a statically configured system.</span></div>
</blockquote><div><br></div><div>I wanted our ops team to be able to bring more collector service instances online when our cloud starts seeing an increase in the sorts of activity that generates metering events, without having to explicitly register the new workers in a configuration file. It sounds like having the zeromq driver (optionally?) communicate to a central registry would let it reproduce some of the features built into AMQP to achieve that sort of dynamic self-configuration.</div>
<div><br></div><div>I mentioned off-list that I'm not a messaging expert, and I wasn't around when the zeromq driver work was started. Is the goal of that work to eventually permanently replace AMQP, or just to provide a compatible alternative?</div>
<div><br></div><div>Doug</div><div><br></div></div>