[rabbitmq-discuss] RabbitMQ 2.6.0 is released

[Jason J. W. Williams]

> Indeed. Personally, I'd be keen to extend AMQP with additional methods
> that allow such things to be manipulated, thus allowing such management
> to be done by any client with the necessary credentials. I find this
> much more appealing than extending mgmt or rabbitmqctl.

Extending AMQP with in-band management would be really interesting.
Before the REST API came along it was something I really wanted to
see. However, I'm really not crazy about extending client-oriented
commands like queue.declare to control HA. In my experience, things
like HA should be as transparent as possible to the
data/client-oriented primitives they make more resilient. For example,
when creating a table in MySQL you don't specify how or where it
should be replicated. That's an operational consideration subject to
flux that should be transparent to the clients/applications using the
service. Similarly in Riak, you only supply the replication factor
when storing data. You don't tell Riak which nodes to put the data on
or if you have the DC-replication plugin, which clusters to replicate
to. It should be possible to change the particulars of
HA/clustering/replication without having to change the clients. It
seems to me to make the clients brittle and subject to breaking every
time you operationally change Rabbit. The "all nodes" setting really
isn't a solution to that. To me, the rule of thumb for deciding where
to control an HA/replication argument should be "will the arguments
have to change if have a topology change? (e.g. remove, rename, or
re-locate a node)". If the answer is yes, then it should be controlled
from a management instead of client/app interface.

-J