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 -- @flaper87 Flavio Percoco
pgpP3OPVlyY6x.pgp
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
