On 23.12.2015 18:50, Matthew Mosesohn wrote: > 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)
For DNS resolve, we could use SRV [0] records perhaps. Although, nodes rely on /etc/hosts instead, AFAIK. So we could as well do net-template-based FQDNs instead, like messaging-node*-domain.local 1.2.3.4 corosync-node*-domain.local 5.6.7.8 database-node*-domain.local 9.10.11.12 and rely on *these* FQDNS instead. [0] https://en.wikipedia.org/wiki/SRV_record > > On Dec 23, 2015 8:42 PM, "Andrew Maksimov" <amaksi...@mirantis.com > <mailto: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 <mailto: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://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > 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 > -- Best regards, Bogdan Dobrelya, Irc #bogdando __________________________________________________________________________ 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
