+1 to Bogdan here. On Thu, Jan 14, 2016 at 4:27 PM, Bogdan Dobrelya <[email protected]> wrote:
> On 28.12.2015 10:12, Bogdan Dobrelya 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. > > > > [0] https://en.wikipedia.org/wiki/SRV_record > > > The original idea with the "fqdn_prefix" OCF RA parameter [0] appeared > the way more simple. It would as well allow to instantiate multiple > rabbit clusters constructed from prefix-based instances of rabbit nodes. > > The complexity with DNS alias is what we have 1) a node name in CIB > (corosync cluster's crm_node -n), 2) a node name as we want it in rabbit > cluster (with some prefix), 3) the actual clustered rabbit node name in > the mnesia DB constructed from the name (2) with the rabbit@<...> prefix > added. > > So, as we often compare those in the RA logic and assume (1) == (2), the > prefix-based solution would be more simple. Otherwise we shall introduce > some translate_name() function, which translates the name (1) into the > name (2), for example using DNS resolving, and fix all of the type (1), > (2), (3) names comparsions in the OCF RA. Which would end up in much > more changes to test and maintain. > > [0] https://review.openstack.org/#/c/262535/8 > > > > >> > >> On Dec 23, 2015 8:42 PM, "Andrew Maksimov" <[email protected] > >> <mailto:[email protected]>> 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 > >> <[email protected] <mailto:[email protected]>> 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: > >> [email protected]?subject:unsubscribe > >> < > http://[email protected]?subject:unsubscribe> > >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > >> [email protected]?subject:unsubscribe > >> < > http://[email protected]?subject:unsubscribe> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > __________________________________________________________________________ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > [email protected]?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: [email protected]?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 [email protected]
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
