Open Stack

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