We are thinking of exposing a portion of our message bus to customers.  To do we we will be creating a new cluster that can be exposed and will be linking it to our existing cluster.  <div><br></div><div>I&#39;ve looked a the Federation plug-in, but it has a feature disqualifies it for our purposes.   We&#39;d like to keep communications from our existing cluster to the new exposed cluster unidirectional.  That means now allowing incoming connections into the existing cluster, in case there is ever a RabbitMQ vulnerability (or say, an Erlang or OpenSSL vulnerability) that would allow the external cluster to be compromised.  Since both cluster are running RabbitMQ, we don&#39;t want an attacker to be able to jump from the external cluster to the internal one.  From what I&#39;ve gathered, the AMQP client that the Federation plug-in uses executed within the downstream broker, and thus it has to be able to make an AMQP connection to the upstream broker.</div>
<div><br></div><div>Is that correct?  Any plans to allow for the opposite behavior (upstream connects to the downstream broker)?</div><div><br></div><div>That leaves us with the Shovel plug-in, which can be configured to run on either the upstream or downstream broker.</div>
<div><br></div><div>One problem with the Shovel plug-in is that it appears you can only manage the shovels within the configuration file.  Is there no way to manage shovels online, either through AMQP or a management plug-in?  </div>
<div><br></div><div>If neither of those are possible, can RabbitMQ reload its configuration without restarting?</div><div><br></div><div>Finally, its unclear whether you should only define a shovel in a single node in a cluster or in multiple ones?  If you define it in multiple ones, does it create multiple shovel clients competing for messages?  If not, will a shovel fail over if the node with the existing client fails?</div>
<div><br></div><div>Elias</div><div><br></div><div><br></div><div><br></div>