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>