Open Stack

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" <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