Open Stack

On Tue, May 22, 2012 at 12:00 PM, Eric Windisch <eric at cloudscaling.com>wrote:

>
> 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.
>
>
> 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.
>

> 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.
>

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.

> 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?
>
> It is currently a compatible alternative.
>
> 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
> ;-)
>

It's definitely good to have options. I'm sure we can find a way to add
this feature and maintain compatibility.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120522/c87f24af/attachment.html>