On Mon, Dec 28, 2015 at 1:13 AM Bogdan Dobrelya <bdobre...@mirantis.com> wrote:
> 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. > This is probably going to be the best way to work out this issue since we can move all of these services around as it is. I would attempt to remove the node identifier if possible so the names aren't wrong if the service is moved between nodes. > [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 > -- -- Andrew Woodward Mirantis Fuel Community Ambassador Ceph Community
__________________________________________________________________________ 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
