Open Stack

> 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.

This captures the key trade off well. I would generalize it a bit to say
that the larger the scope of the HTTP API, the fewer implementation
choices exist, and the harder it is to provide a performant system; that
holds regardless if the implementation is based on an existing technology
or a brand new one.

With respect to that trade off, I am in favor of a minimalist HTTP
contract with queue based semantics (SQS like) that provides more
implementation choices and more room for optimization.

Tomasz Janczuk
@tjanczuk
HP

On 6/10/14, 2:03 PM, "Mark McLoughlin" <markmc at redhat.com> wrote:

>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 at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev