Open Stack

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

Thanks,
Tomasz Janczuk
@tjanczuk
HP

On 6/10/14, 10:12 AM, "Kurt Griffiths" <kurt.griffiths at rackspace.com>
wrote:

>> Will Marconi only support HTTP as a transport, or will it add other
>>protocols as well?
>
>We are focusing on HTTP for Juno, but are considering adding a
>lower-level, persistent transport (perhaps based on WebSocket) in the K
>cycle.
>
>> Can anyone describe what is unique about the Marconi design with respect
>>to scalability?
>
>TBH, I don¹t know that there is anything terribly ³unique² about it. :)
>
>First of all, since Marconi uses HTTP and follows the REST architectural
>style, you get all the associated scaling benefits from that.
>
>Regarding the backend, Marconi has a notion of ³pools", across which
>queues can be sharded. Messages for an individual queue may not be
>sharded across  multiple pools, but a single queue may be sharded
>within a given pool,  depending on whether the driver supports it. In
>any case, you can imagine each pool as encapsulating a single DB or
>broker cluster. Once you reach the limits of scalability within your
>initial pool (due to networking, hard limitations in the given backend,
>etc.), you can provision other pools as needed.
>
>> in what way is Marconi different to 'traditional message brokers' (which
>>after all have been providing 'a production queuing service' for some
>>time)?
>
>That¹s a great question. As I have said before, I think there is certainly
>room for some kind of broker-as-a-service in the OpenStack ecosystem that
>is more along the lines of Trove. Such a service would provision
>single-tenant instances of a given broker and provide a framework for
>adding value-add management features for said broker.
>
>For some use cases, such a service could be a cost-effective solution, but
>I don¹t think it is the right answer for everyone. Not only due to cost,
>but also because many developers (and sys admins) actually prefer an
>HTTP-based API. Marconi¹s multi-tenant, REST API was designed to serve
>this market. 
>
>> I understand that having HTTP as the protocol used by clients is of
>>central importance. However many 'traditional message brokers¹ have
>>offered that as well.
>
>Great point. In fact, I¹d love to get more info on brokers that offer
>support for HTTP. What are some examples? Do they support multi-tenancy?
>
>-KG
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev