[openstack-dev] [fuel] RabbitMQ in dedicated network
mmosesohn at mirantis.com
Wed Dec 23 17:50:08 UTC 2015
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.
> Andrey Maximov
> Fuel Project Manager
> On Wed, Dec 23, 2015 at 8:24 PM, Kyrylo Galanov <kgalanov at mirantis.com>
>> I would like to start discussion regarding the issue we have discovered
>> recently .
>> 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.
>>  https://bugs.launchpad.net/fuel/+bug/1528707
>> Best regards,
>> OpenStack Development Mailing List (not for usage questions)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev