<p dir="ltr">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)</p>
<div class="gmail_quote">On Dec 23, 2015 8:42 PM, "Andrew Maksimov" <<a href="mailto:amaksimov@mirantis.com">amaksimov@mirantis.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Kirill,<div><br></div><div>I don't think we can give up on using fqdn node names for RabbitMQ because we need to support TLS in the future. </div><div><br></div><div>Thanks,</div><div>Andrey Maximov</div><div>Fuel Project Manager</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 23, 2015 at 8:24 PM, Kyrylo Galanov <span dir="ltr"><<a href="mailto:kgalanov@mirantis.com" target="_blank">kgalanov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hello,<div><br></div><div>I would like to start discussion regarding the issue we have discovered recently [1].</div><div><br></div><div>In a nutshell, if RabbitMQ is configured to run in separate mgmt/messaging network it fails on building cluster.</div><div>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.</div><div>As a result, RabbitMQ on secondary controller node fails to join to primary controller node.</div><div><br></div><div>I can suggest two ways to tackle the issue: one is pretty simple, while other is not.</div><div><br></div><div>The first way is to accept by design using admin network for RabbitMQ internal communication between controller nodes.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>--<br></div><div>[1] <a href="https://bugs.launchpad.net/fuel/+bug/1528707" target="_blank">https://bugs.launchpad.net/fuel/+bug/1528707</a></div><div><br></div><div>Best regards,</div><div>Kyrylo</div></div>
<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>
<br></blockquote></div><br></div>
<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>
<br></blockquote></div>