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

Flavio Percoco flavio at redhat.com
Wed Jun 11 12:28:40 UTC 2014

On 11/06/14 13:01 +0100, Gordon Sim wrote:
>On 06/11/2014 12:31 PM, Flavio Percoco wrote:
>>>On 06/10/2014 09:59 PM, Mark McLoughlin wrote:
>>>>Now why is there a desire to implement these requirements using
>>>>traditional message brokers?
>>There are 2 main reasons that I don't believe are strong enough to
>>change the way Marconi works right now:
>>1. Being able to support technologies that many deployments have
>>already deployed. This will facilitate Marconi's adoption but it also
>>brings in Marconi's scaling capabilities to those environments.
>Is there somewhere I can read more about the mechanism behind those 
>capabilities? (I.e. the mechanisms that Marconi implements independent 
>of a given driver to allow scaling). Or can you describe it a little?

s/capabilities/capability/ :D

There are three things that I consider really valuable:

1. Sharding support: It allows admins to have separate clusters/nodes
of stores and configure marconi to use them all based on
pre-configured rules. It's similar to what qpid-dispatch does but the
supported rules in marconi are currently very limited.

(the next 2 are in currently being developed)

2. Storage flavors: It'll allow users to choose on which storage type
a queue should be created based on their "queue needs". For example, a
high-throughput queue would likely go to a store like rabbitmq whereas
a "volatile" queue could be kept in redis.

3. Queue's migrations: It'll allow users to migrate queues from one
store to another. During the first release, we're targeting migrations
between stores of the same type - rabbit->rabbit, mongodb->mongodb -
but we'll likely add support to cross-type migrations too. Just
playing safe.


Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140611/02dcfe0a/attachment.pgp>

More information about the OpenStack-dev mailing list