[rabbitmq-discuss] Automating a RabbitMQ 3.0 cluster on EC2

[Francesco Mazzoli]

At Fri, 28 Dec 2012 12:26:52 +0100,
Mathias Meyer wrote:
> Regarding changing the host name, I tried that, and from my experiments, that
> didn't seem to work properly. But that might have been related again to the
> hostname temporarily not being resolvable.

What did you do, and what didn’t work?  It’s impossible for us to diagnose a
problem without the symptoms.

> The partitioning was mostly conjecture. It might happen, and it's still
> fixable if it does. The whole mechanism just strikes me as less than ideal
> when it comes to automating a cluster setup.

This is set of assumptions that comes from a well established theorem:
<https://en.wikipedia.org/wiki/CAP_theorem>.  RabbitMQ clustering sits on the CA
side of things, with some limited support for partitioning.  We provide other
solutions that offer different guarantees, see
<http://www.rabbitmq.com/distributed.html>.

> They might seem different on the surface, but given how the RabbitMQ package
> installer works, they bot converge into the issue of automating and
> customizing a cluster setup.

I’m not sure what you mean here.  What does “RabbitMQ package” refers to?  Can
you be more clear on why “they converge into the same issue”?

> Are all of them documented? Looking at the documentation, it seems to be
> mostly straight-forward, except for the netsplits. If there are that many
> subtleties, I sure wish they'd be mentioned properly in the documentation.

Well, here to change clustering behavior you would probably have to force
things a bit, either with “dangerous” commands or by `eval'ing Erlang
expressions - so you’d be delving into clustering internals that, as
implementation details, are not documented.

Note that you can also deploy some gentler measures like “check that the node
has clustered, try again in 5 minutes if it didn’t”, but those would be ad-hoc
measures that we can’t generalize as default behaviour.

> The cluster is going to run with all nodes in a single available
> zone. Netsplits are unavoidable in any network but are less likely to happen
> in a setup like that.

Netsplits are tolerated to a certain extent, but currently we don’t precisely
specify the semantics of the recovery mechanisms.  What’s surely the case is
that to use `join_cluster' both nodes have to be online - this is not that much
about netsplits but about `join_cluster' being an operation that requires
agreement from 2 parties.

> My biggest question still remains unanswered unfortunately: how do folks go
> about automating a cluster setup, with or without the issues described in my
> original email?

I’m still not sure what your problem is exactly.  If the above makes sense,
`join_cluster' should serve your needs.  For what concerns the hostname
problems, I’m waiting for more details.

Francesco