Open Stack

On Mon, Dec 28, 2015 at 1:13 AM Bogdan Dobrelya <bdobrelia at 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" <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
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151228/0bffdc54/attachment.html>