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 <alebe...@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" <amaksi...@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 <kgala...@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-requ...@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 vkuk...@mirantis.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
