<br><br><div class="gmail_quote">On Tue, May 22, 2012 at 12:00 PM, 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 class="im">
                <br><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><span><div><div><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></div></div></span></blockquote><div><span style="font-size:12px"><br></span></div></div><div><span style="font-size:12px">Understood.  Supporting the dynamic case is viable, I just don't want to (blindly) do it at the expense of static configurations.  Here, I think we can simply warn/error if a static configuration is in place.</span></div>
</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div><span style="font-size:12px">I'm thinking that the zeromq driver would support create_workers by passing the call into the matchmaker.  Some matchmakers would support it, others would not (and would be static), logging a message.  The question might be if we should create an exception and raise this as well, or not, but I'm leaning toward not.</span></div>
</blockquote><div><br></div><div>If a consumer is trying to subscribe to a worker pool but the underlying implementation for the messaging system does not support those semantics, we should fail loudly and explicitly instead of configuring the consumer using other semantics that may result in subtle bugs or data corruption.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
<span><div><div><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></div></div></div></div></span></blockquote></div><div><span style="font-size:12px">It is currently a compatible alternative.</span></div><div><span style="font-size:12px"><br></span></div><div><span style="font-size:12px">We do intend for this to remain compatible, and for the abstraction to be useful across all the available messaging  plugins.  It remains to be seen which, if any, messaging platform will be the /default/ in Nova/OpenStack long-term.  Currently, RabbitMQ is the default, but Essex introduced Qpid messaging, and we'll have ZeroMQ messaging if we can get it out of review ;-)</span></div>
</blockquote><div><br></div><div>It's definitely good to have options. I'm sure we can find a way to add this feature and maintain compatibility.</div><div><br></div><div>Doug</div><div><br></div></div>