DNS-aware federation

[zhicwu]

We have RabbitMQ deployed in multiple data centers and we're using federation. When we change RabbitMQ upstream nodes from one data center to another, we hope federation link can be restarted automatically so that we don't have to shutdown standby instances.

Will you guys consider this feature request? It would be great to have it for less operation cost. Currently we have to use a scheduled shellscript to restart federation links when DNS of upstream nodes changed.

[michaelklishin]

I'm afraid monitoring DNS records is way out of scope for this plugin, Shovel and the Erlang client it uses under the hood. A separate plugin could do that and restart all currently running links. If there are missing API elements for doing so, please file a new set of specific issues, we'd be happy to extend the API as needed.

[michaelklishin]

Alternatively we can make it easier to restart all links for external monitoring tools such as the one you have already.

[zhicwu]

Thanks @michaelklishin. I was hoping you guys can make all connections DNS-aware ;)

I use REST API in shell script as curl is more efficient(and with less CPU usage) compare to rabbitmqctl, with one exception: restarting federation link. The reasons are: 1) the API is not documented at here 2) the endpoint is not convenient(extra vhost in path and why node name there?), and the request body seems duplicated and not necessary

curl -v -X DELETE \
    -d {"id":"<link id>","node":"<node name>","vhost":"<vhost name>"} \
    localhost:15672/api/federation-links/vhost/<vhost name>/<link id>/<node name(encoded)>/restart

I thought about patching federation plugin later but you're right about that, we probably need a new plugin.

[michaelklishin]

All connections are "DNS aware" as hostnames are resolved for them. They do not monitor DNS records, however, and I am unaware of a messaging client library that does, for any protocol I am reasonably familiar with.

The API reference does not cover plugins (it ships with the management plugin), however, neither does rabbitmq-federation-management's brief API reference. We'd appreciate a PR that adds the missing endpoint.

As for why a node name is required, the API endpoint needs to know what node to contact. Federation link state is currently largely node-local. Before that changes, I don't think we would be interested in providing a different endpoint. We might rearchitect this plugin in 3.9 or 4.0.