Open Stack

On Tue, 2014-06-10 at 21:59 +0100, Mark McLoughlin wrote:
> On Tue, 2014-06-10 at 17:33 +0000, Janczuk, Tomasz wrote:
> > From my perspective the key promise of Marconi is to provide a
> > *multi-tenant*, *HTTP* based queuing system. Think an OpenStack equivalent
> > of SQS or Azure Storage Queues.
> > 
> > As far as I know there are no off-the-shelve message brokers out these
> > that fit that bill.
> > 
> > Note that when I say ³multi-tenant² I don¹t mean just having multi-tenancy
> > concept reflected in the APIs. The key aspect of the multi-tenancy is
> > security hardening against a variety of attacks absent in single-tenant
> > broker deployments. For example, an authenticated DOS attack.
> 
> Nicely described.
> 
> Now why is there a desire to implement these requirements using
> traditional message brokers?
> 
> And what Marconi API semantics are impossible to implement using
> traditional message brokers?

Ah, my apologies. This question answered most excellently here:

http://lists.openstack.org/pipermail/openstack-dev/2014-June/037177.html

Mark.

> Either those semantics are fundamental requirements for this API, or the
> requirement to have support for traditional message brokers is the
> fundamental requirement. We can't have it both ways.
> 
> My suspicion is the API semantics are seen by the Marconi team as the
> fundamental requirement, and the support for message brokers is very
> much a secondary concern. If that's the case, perhaps just label those
> drivers as "experimental and not recommended" and allow them to return a
> 501 Not Implemented? Yes, it sucks for portability, but all you're doing
> is creating space for experimenting with backing Marconi with a message
> broker ... not actually recommending it for deployment.
> 
> Mark.