[rabbitmq-discuss] Config file syntax changes between 2.8.7 and 3.0.X

[Simon MacMullen]

On 06/02/13 22:12, Matt Pietrek wrote:
> *1) Specifying a node as a 'disc' node in the cluster config*
>
> In http://previous.rabbitmq.com/clustering.html, the cluster node list
> example looks like this:
>
> {cluster_nodes, ['rabbit at rabbit1', 'rabbit at rabbit2']},
>
> In the current 3.0.X clustering.html, it show this:
>
> {cluster_nodes, {['rabbit at rabbit1', 'rabbit at rabbit2', 'rabbit at rabbit3'], disc}},
>
> Note the addition of the 'disc' near the end.
>
> Is the 'disc' only allowed in 3.0.X config files? I know 'disc' is the
> default, but in a 3.0.X cluster, I was seeing a node start as 'ram'
> unless I specified it. But then trying to start a 2.8.7 broker with
> 'disc" specified resulted in the inability to start it.

The two configs are actually a bit more different than that; the meaning 
of the list of nodes differs.

In 2.x the list of nodes must contain *all* the disc nodes in the 
cluster; in order to become a disc node the node itself must be listed 
there.

In 3.x the list of nodes denotes a list of nodes to try communicating 
with. RabbitMQ will find one which is up, get the real state of the 
cluster from that node, and join as either a disc or ram node according 
to the config.

For backwards compatibility 3.x has the ability to read the 2.x style 
config - in which case the node type will be inferred from whether the 
node is in the list of nodes. A warning also gets written to logs in 
this case.

> *2) Configuring the Management API port*
>
> In the http://previous.rabbitmq.com/management.html, the management port
> looks to be configured like this:
>
> {rabbitmq_mochiweb, [{listeners, [{mgmt, [{port, 55555}]}]}]},
>
>
> whereas in 3.0.X, it looks like the port is configured like this:
>
> {rabbitmq_management, [{listener, [{port, 12345}]}]},
>
>
> Is the 2.8.7 syntax not allowed in 3.0.X?

No, that's just changed outright.

The good news is we are not planning to make breaking changes like this 
again any time soon...

Cheers, Simon

-- 
Simon MacMullen
RabbitMQ, VMware