The nova rpc implementation is moving into openstack common, I agree with using this abstraction.
As per ZeroMQ, I'm the author of that plugin. There is a downloadable plugin for Essex and I'm preparing to make a Folsom merge prop within the next week or so, if all goes well. Sent from my iPad On May 18, 2012, at 7:26, Doug Hellmann <doug.hellm...@dreamhost.com> wrote: > > > On Fri, May 18, 2012 at 4:42 AM, Nick Barcet <nick.bar...@canonical.com> > wrote: > Hello everyone, > > Next week's irc meeting will have for goal to choose a reference > messaging queue service for the ceilometer project. For this meeting to > be able to be successful, a discussion on the choices that we have to > make need to occur first right here. > > To open the discussion here are a few requirements that I would consider > important for the queue to support: > > a) the queue must guaranty the delivery of messages. > To the contrary of monitoring, loss of events may have important billing > impacts, it therefore cannot be an option that message be lost. > > b) the client should be able to store and forward. > As the load of system or traffic increases, or if the client is > temporarily disconnected, client element of the queue should be able to > hold messages in a local queue to be emitted as soon as condition permit. > > c) client must authenticate > Only client which hold a shared private key should be able to send > messages on the queue. > > Does the username/password authentication of rabbitmq meet this requirement? > > > d) queue may support client signing of individual messages > Each message should be individually signed by the agent that emits it in > order to guaranty non repudiability. This function can be done by the > queue client or by the agent prior to en-queuing of messages. > > We can embed the message signature in the message, so this requirement > shouldn't have any bearing on the bus itself. Unless I'm missing something? > > > d) queue must be highly available > the queue servers must be able to support multiple instances running in > parallel in order to support continuation of operations with the loss of > one server. This should be achievable without the need to use complex > fail over systems and shared storage. > > e) queue should be horizontally scalable > The scalability of queue servers should be achievable by increasing the > number of servers. > > Not sure this list is exhaustive or viable, feel free to comment on it, > but the real question is: which queue should we be using here? > > While I see the benefit of discussing requirements for the message bus > platform in general, I'm not sure we need to dictate a specific > implementation. If we say we are going to use the nova RPC library to > communicate with the bus for sending and receiving messages, then we can use > all of the tools for which there are drivers in nova -- rabbit, qpid, zeromq > (assuming someone releases a driver, which I think is being worked on > somewhere), etc. This leaves the decision of which bus to use up to the > deployer, where the decision belongs. It also means we won't end up choosing > a tool for which the other projects have no driver, leading us to have to > create one and add a new dependency to the project. > > Doug > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
