[openstack-dev] [fuel] RabbitMQ in dedicated network

Alexey Lebedeff alebedev at mirantis.com
Wed Dec 23 18:27:44 UTC 2015

When long node names are enabled (controlled by RABBITMQ_USE_LONGNAME
environment variable), you could actually use IP-address as a node name.

Matthew Mosesohn writes:

> I agree. As far as I remember, rabbit needs fqdns to work and map
> correctly. I think it means we should disable the ability to move the
> internal messaging network role in order to fix this bug until we can add
> extra dns entries per network role (or at least addr)
> On Dec 23, 2015 8:42 PM, "Andrew Maksimov" <amaksimov at mirantis.com> wrote:
>> Hi Kirill,
>> I don't think we can give up on using fqdn node names for RabbitMQ because
>> we need to support TLS in the future.
>> Thanks,
>> Andrey Maximov
>> Fuel Project Manager
>> On Wed, Dec 23, 2015 at 8:24 PM, Kyrylo Galanov <kgalanov at mirantis.com>
>> wrote:
>>> Hello,
>>> I would like to start discussion regarding the issue we have discovered
>>> recently [1].
>>> In a nutshell, if RabbitMQ is configured to run in separate
>>> mgmt/messaging network it fails on building cluster.
>>> While RabbitMQ is managed by Pacemaker and OCF script, the cluster is
>>> built using FQDN. Apparently, FQDN resolves to admin network which is
>>> different in this particular case.
>>> As a result, RabbitMQ on secondary controller node fails to join to
>>> primary controller node.
>>> I can suggest two ways to tackle the issue: one is pretty simple, while
>>> other is not.
>>> The first way is to accept by design using admin network for RabbitMQ
>>> internal communication between controller nodes.
>>> The second way is to dig into pacemaker and RabbitMQ reconfiguration.
>>> Since it requires to refuse from using common fqdn/node names, this
>>> approach can be argued.
>>> --
>>> [1] https://bugs.launchpad.net/fuel/+bug/1528707
>>> Best regards,
>>> Kyrylo

More information about the OpenStack-dev mailing list