<div dir="ltr">+1 to Bogdan here.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 14, 2016 at 4:27 PM, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 28.12.2015 10:12, Bogdan Dobrelya wrote:<br>
> On 23.12.2015 18:50, Matthew Mosesohn wrote:<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<br>
>> add extra dns entries per network role (or at least addr)<br>
><br>
> For DNS resolve, we could use SRV [0] records perhaps.<br>
> Although, nodes rely on /etc/hosts instead, AFAIK.<br>
><br>
> So we could as well do net-template-based FQDNs instead, like<br>
> messaging-node*-domain.local 1.2.3.4<br>
> corosync-node*-domain.local 5.6.7.8<br>
> database-node*-domain.local 9.10.11.12<br>
><br>
> and rely on *these* FQDNS instead.<br>
><br>
> [0] <a href="https://en.wikipedia.org/wiki/SRV_record" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/SRV_record</a><br>
<br>
<br>
</span>The original idea with the "fqdn_prefix" OCF RA parameter [0] appeared<br>
the way more simple. It would as well allow to instantiate multiple<br>
rabbit clusters constructed from prefix-based instances of rabbit nodes.<br>
<br>
The complexity with DNS alias is what we have 1) a node name in CIB<br>
(corosync cluster's crm_node -n), 2) a node name as we want it in rabbit<br>
cluster (with some prefix), 3) the actual clustered rabbit node name in<br>
the mnesia DB constructed from the name (2) with the rabbit@<...> prefix<br>
added.<br>
<br>
So, as we often compare those in the RA logic and assume (1) == (2), the<br>
prefix-based solution would be more simple. Otherwise we shall introduce<br>
some translate_name() function, which translates the name (1) into the<br>
name (2), for example using DNS resolving, and fix all of the type (1),<br>
(2), (3) names comparsions in the OCF RA. Which would end up in much<br>
more changes to test and maintain.<br>
<br>
[0] <a href="https://review.openstack.org/#/c/262535/8" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/262535/8</a><br>
<div class="HOEnZb"><div class="h5"><br>
><br>
>><br>
>> On Dec 23, 2015 8:42 PM, "Andrew Maksimov" <<a href="mailto:amaksimov@mirantis.com">amaksimov@mirantis.com</a><br>
>> <mailto:<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<br>
>> because 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<br>
>> <<a href="mailto:kgalanov@mirantis.com">kgalanov@mirantis.com</a> <mailto:<a href="mailto:kgalanov@mirantis.com">kgalanov@mirantis.com</a>>> wrote:<br>
>><br>
>> Hello,<br>
>><br>
>> I would like to start discussion regarding the issue we have<br>
>> discovered 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<br>
>> cluster is built using FQDN. Apparently, FQDN resolves to admin<br>
>> network which is different in this particular case.<br>
>> As a result, RabbitMQ on secondary controller node fails to join<br>
>> to primary controller node.<br>
>><br>
>> I can suggest two ways to tackle the issue: one is pretty<br>
>> simple, while other is not.<br>
>><br>
>> The first way is to accept by design using admin network for<br>
>> RabbitMQ internal communication between controller nodes.<br>
>><br>
>> The second way is to dig into pacemaker<br>
>> and RabbitMQ reconfiguration. Since it requires to refuse from<br>
>> using common fqdn/node names, this 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:<br>
>> <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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe:<br>
>> <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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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>
>><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>
>><br>
><br>
><br>
<br>
<br>
--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<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>