[rabbitmq-discuss] Federation vs Shovel

[Simon MacMullen]

On 21/03/2014 16:25, Danny Beutler wrote:
> Using Federation, I am not fully aware of what would happen. Say I have
> a fanout exchange configured at Site A. A queue at Site A connects to
> this queue for local consumption of the messages. Site B then attaches
> to the exchange via federation. My understanding is that there is then
> an upstream queue created.

Yes.

> If Site B then goes offline, what happens to
> the messages published to the fanout exchange in Site A. Will the
> messages sit in the upstream queue until both the queue and the remote
> are available to fanout messages to?

They will sit in the upstream queue until site B comes back, then be 
republished there.

> 2) Shovel has "More Control" according to the documentation.

"More control" is a bit vague, but I am not quite sure how to improve 
it. It means that shovel is a lower-level tool; you're responsible for 
the wiring and it's a bit more YAFIYGI.

> My questions are: Am I missing the boat? Would Federation be much more
> simple to setup? Would Federation even work in this scenario?

Really it's up to you. Where exchange federation would win in this 
scenario is if you want to ensure that only messages which are actually 
needed at site B (because there's an appropriately bound queue) get sent 
there - federation is aware of which bindings exist, shovel isn't.

> In addition: I would like to configure this whole thing via Puppet. I
> know how to do it in the rabbitmq config for shovel but wouldn't this
> require a restart when configuration changes are made?

Yes.

> Also, would the
> federation configuration methods via the API lend itself to more simple
> Puppetization through simple API calls for Federation setup?

Quite possibly.

The next release of RabbitMQ (3.3.0) will give you the option of 
configuring the shovel in a similar way to federation, via mgmt/ctl 
calls with changes applied immediately (see 
http://next.rabbitmq.com/shovel-dynamic.html).

I don't know if that makes your choice harder ;-)

Cheers, Simon