[openstack-dev] [fuel] RabbitMQ in dedicated network

Vladimir Kuklin vkuklin at mirantis.com
Thu Jan 14 14:28:18 UTC 2016


+1 to Bogdan here.

On Thu, Jan 14, 2016 at 4:27 PM, Bogdan Dobrelya <bdobrelia at mirantis.com>
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" <amaksimov at mirantis.com
> >> <mailto: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 <mailto: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://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> >>     <
> http://OpenStack-dev-request@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-request at 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-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/20160114/d02a350c/attachment.html>


More information about the OpenStack-dev mailing list