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. Mark. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
