openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

On Fri, Feb 18, 2011 at 11:20:23AM -0600, Monsyne Dragon wrote:
> Secondly,  could we leverage existing opensource codebases to
> accomplish this?  I know AMQP was having issues over WAN links, and
> likely isn't suited for disconnected operations (I've seen one
> multitenant hosted queueing service offering AMQP interfaces
> (StormMQ), but they also offer a a REST interface as well, probably
> for that reason.), but could we swipe the core of some existing
> queueing system and adapt it?

There isn't a whole lot out there, and nothing I think is appropriate
for our use case. ActiveMQ has a REST API that maps onto JMS, but this
brings a lot of complexity (and Java). The only other open source
REST queue that seems to have use is Resque, which is a Ruby REST
API on top of Redis. It's nice, but nothing that would serve as a
good building block for a high-performance multi-tenant service. We
can use Redis as one of the pluggable data stores though down the road.

> Or, before we implement Yet Another Queueing Service, would it be
> possible to implement this using a REST interface plugin to say,
> rabbitMQ,  using it's 'virtual hosts' for multitenant separation,
> plus a  modest amount of code to arrange for needed zone/locality
> awareness on the cluster?

I also looked into this, RabbitMQ being the most obvious choice. The
problem with REST on Rabbit is while you avoid the AMQP protocol
issues, you still get the routing complexity in the RabbitMQ core. This
complexity comes at a price (efficiency and overall throughput),
where a much simpler routing service like the one proposed on the
wiki would be easier to scale. It's certainly a possibility, but I
don't think it's the optimal path.

> I just worry, since reliable queueing is one of those things that is
> simple in concept, but has an awful lot of nasty details. (That
> said, I have no objection to re-inventing wheels if a: our new ones
> fly, or b: the existing ones are square :>  )

I think the main issue is that for our use case, the existing ones are
square, maybe with rounded edges, but certainly not a perfect wheel. :)
They are great for their use cases, but nothing is really built
"for the multi-tenant public cloud". Few people have this problem,
and the ones who solved it already are no open source.

The nice thing is there is plenty of software we can build from, I'm
certainly not advocating writing things like our own persistent store,
but rather just writing the core and plugin interfaces and finding
ways to patch in existing projects that fit well. For example, with
Erlang, Basho (the folks behind Riak) have a number of great Erlang
modules we can use for persistent storage options.

-Eric