[rabbitmq-discuss] RabbitMQ 2.6.0 is released

[Jason J. W. Williams]

Hi Matthias,

> Different types of replication policies are on the todo list. We agonised
> about this for quite some time during development, and in the end decided to
> ship with just the two policies - 'all' is as simple as it gets and 'nodes'
> gives you ultimate flexibility
>
> We seek input from the community and what policies they'd like to see, and
> how exactly they should work. E.g. in the above "replication factor" policy,
> how are the nodes a queue gets replicated to chosen? what happens when there
> are fewer nodes than the policy dictates? etc. etc.

Personally what I'd like to see is the ability to create "cluster
groups" to which nodes could be assigned when they are joined to a
cluster. These groups would then be the basis of "rack-aware" or
"datacenter-aware" decisions. It would make a lot more sense in our
environment to tell queue.declare, set the replication-factor to 4
(example) and spread the copies across the nodes in rack1_group and
rack2_group (letting RabbitMQ figure out the best way to do that given
current loading and node-presence). Or in a more basic mode, spread
the spec'd # of copies across as many cluster groups as possible.
Nodes and their names can be fairly transient, but administrative
groupings would remain more static regardless of the nodes added or
joined to them.

-J