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