[openstack-dev] [fuel] RabbitMQ in dedicated network
vkuklin at mirantis.com
Thu Dec 24 03:48:17 UTC 2015
One comment here. Hostname on the nodes resolves to its management network
as it is put into /etc/hosts file during the deployment.
On Wed, Dec 23, 2015 at 9:27 PM, Alexey Lebedeff <alebedev at mirantis.com>
> 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>
> >> Hi Kirill,
> >> I don't think we can give up on using fqdn node names for RabbitMQ
> >> 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 .
> >>> 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,
> >>> Kyrylo
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
Fuel Library Tech Lead,
+7 (495) 640-49-04
+7 (926) 702-39-68
35bk3, Vorontsovskaya Str.
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev