Open Stack

Kyrylo

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>
wrote:

>
> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151224/9dcbe368/attachment.html>