<div dir="ltr">Kyrylo<div><br></div><div>One comment here. Hostname on the nodes resolves to its management network as it is put into /etc/hosts file during the deployment.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 23, 2015 at 9:27 PM, Alexey Lebedeff <span dir="ltr"><<a href="mailto:alebedev@mirantis.com" target="_blank">alebedev@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
When long node names are enabled (controlled by RABBITMQ_USE_LONGNAME<br>
environment variable), you could actually use IP-address as a node name.<br>
<div class="HOEnZb"><div class="h5"><br>
Matthew Mosesohn writes:<br>
<br>
> I agree. As far as I remember, rabbit needs fqdns to work and map<br>
> correctly. I think it means we should disable the ability to move the<br>
> internal messaging network role in order to fix this bug until we can add<br>
> extra dns entries per network role (or at least addr)<br>
> On Dec 23, 2015 8:42 PM, "Andrew Maksimov" <<a href="mailto:amaksimov@mirantis.com">amaksimov@mirantis.com</a>> wrote:<br>
><br>
>> Hi Kirill,<br>
>><br>
>> I don't think we can give up on using fqdn node names for RabbitMQ because<br>
>> we need to support TLS in the future.<br>
>><br>
>> Thanks,<br>
>> Andrey Maximov<br>
>> Fuel Project Manager<br>
>><br>
>> On Wed, Dec 23, 2015 at 8:24 PM, Kyrylo Galanov <<a href="mailto:kgalanov@mirantis.com">kgalanov@mirantis.com</a>><br>
>> wrote:<br>
>><br>
>>> Hello,<br>
>>><br>
>>> I would like to start discussion regarding the issue we have discovered<br>
>>> recently [1].<br>
>>><br>
>>> In a nutshell, if RabbitMQ is configured to run in separate<br>
>>> mgmt/messaging network it fails on building cluster.<br>
>>> While RabbitMQ is managed by Pacemaker and OCF script, the cluster is<br>
>>> built using FQDN. Apparently, FQDN resolves to admin network which is<br>
>>> different in this particular case.<br>
>>> As a result, RabbitMQ on secondary controller node fails to join to<br>
>>> primary controller node.<br>
>>><br>
>>> I can suggest two ways to tackle the issue: one is pretty simple, while<br>
>>> other is not.<br>
>>><br>
>>> The first way is to accept by design using admin network for RabbitMQ<br>
>>> internal communication between controller nodes.<br>
>>><br>
>>> The second way is to dig into pacemaker and RabbitMQ reconfiguration.<br>
>>> Since it requires to refuse from using common fqdn/node names, this<br>
>>> approach can be argued.<br>
>>><br>
>>><br>
>>> --<br>
>>> [1] <a href="https://bugs.launchpad.net/fuel/+bug/1528707" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1528707</a><br>
>>><br>
>>> Best regards,<br>
>>> Kyrylo<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>