[openstack-dev] [marconi] Reconsidering the unified API model

Mark McLoughlin markmc at redhat.com
Tue Jun 10 20:59:16 UTC 2014

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?

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.


More information about the OpenStack-dev mailing list