> 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. > 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 ;-) Regards, Eric Windisch
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
