[rabbitmq-discuss] RabbitMQ Roadmap

Thu May 24 11:33:31 BST 2012

Good stuff!

The physical layout comment is regarding having to specify -sname/-name in
the x-ha-policy .. ie having clients aware of the nodes that compose a
cluster.
In the imaginary places in my head it would be nicer to set something along
the lines of 'one slave', 'two slaves', ..., or '50% of the cluster has
slaves' etc.

Migrating/moving a queue around inside a cluster is another nice to have
- scenario would be whatever you're using to do load-balancing
throws a nana and causes too many queues to be declared on a single machine
vs a more desired even spread. Basically fine tuning your queue
distribution, on the fly.

Thanks,
Brendan

On Thu, May 24, 2012 at 12:02 PM, Simon MacMullen <simon at rabbitmq.com>wrote:

> On 24/05/12 09:47, Brendan Hay wrote:
>
>> Yo!
>>
>> There's been a few hints dropped here towards future changes in
>> Federation, Mirrored Queues, and making things a bit more transparent to
>> clients regarding physical topology layout.
>>
>> Do you dudes have some sort of non-committal timeline/roadmap to share?
>> (Off the record is fine, we won't hold you to anything.)
>>
>
> Matthias always hates it when I make any sort of forward looking
> prediction. But I'm in an uncooperative mood today, so here we go. All
> remarks here are extremely tentative and should not be taken as any sort of
> guarantee of anything happening.
>
> There will probably be a 2.8.3 release soon, with bug fixes only.
>
> 2.9.0 should happen at some point in the summer (for a broad definition of
> summer). Some of the more major new things we're hoping to do include:
>
> * Take federation configuration out of the config file and make it
> dynamically changeable with rabbitmqctl / mgmt
>
> * Stop federation from being an exchange type, make regular exchanges
> federated through dynamically changeable policy managed by the sysadmin
>
> * Similarly, make HA status of queues manageable dynamically by the
> sysadmin, not statically by the application programmer
>
> * Rework clustering commands to make clustering clearer and less error
> prone
>
> Although obviously I can't guarantee that all of these will be in 2.9.0
> (or will ever happen; plans are constantly shifting). But those are the big
> things I want to see (along with lots of smaller features and bug fixes I'm
> sure).
>
> By the way, what do you mean by "making things a bit more transparent to
> clients regarding physical topology layout"?
>
>
>  I'm personally interested in things such as dynamic upstream_sets, a
>> better mechanism for specifying x-ha-policy to a subset, moving
>> master/declared queues around inside a cluster and things related to
>> making RabbitMQ more manageable in higher throughput scenarios.
>>
>
> Hopefully you should get many of these.
>
> Cheers, Simon
>
> --
> Simon MacMullen
> RabbitMQ, VMware
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20120524/ac633cd8/attachment.htm>