Re: [openstack-dev] [fuel] RabbitMQ in dedicated network

2016-01-14 Thread Vladimir Kuklin 
+1 to Bogdan here.

On Thu, Jan 14, 2016 at 4:27 PM, Bogdan Dobrelya 
wrote:

> On 28.12.2015 10:12, Bogdan Dobrelya 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.
> >
> > [0] https://en.wikipedia.org/wiki/SRV_record
>
>
> The original idea with the "fqdn_prefix" OCF RA parameter [0] appeared
> the way more simple. It would as well allow to instantiate multiple
> rabbit clusters constructed from prefix-based instances of rabbit nodes.
>
> The complexity with DNS alias is what we have 1) a node name in CIB
> (corosync cluster's crm_node -n), 2) a node name as we want it in rabbit
> cluster (with some prefix), 3) the actual clustered rabbit node name in
> the mnesia DB constructed from the name (2) with the rabbit@<...> prefix
> added.
>
> So, as we often compare those in the RA logic and assume (1) == (2), the
> prefix-based solution would be more simple. Otherwise we shall introduce
> some translate_name() function, which translates the name (1) into the
> name (2), for example using DNS resolving, and fix all of the type (1),
> (2), (3) names comparsions in the OCF RA. Which would end up in much
> more changes to test and maintain.
>
> [0] https://review.openstack.org/#/c/262535/8
>
> >
> >>
> >> On Dec 23, 2015 8:42 PM, "Andrew Maksimov"  >> > 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
> >> mailto:kgala...@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-requ...@lists.openstack.org?subject:unsubscribe
> >> <
> http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> >> <
> http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.open

Re: [openstack-dev] [fuel] RabbitMQ in dedicated network

2016-01-14 Thread Bogdan Dobrelya 
On 28.12.2015 10:12, Bogdan Dobrelya 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.
> 
> [0] https://en.wikipedia.org/wiki/SRV_record


The original idea with the "fqdn_prefix" OCF RA parameter [0] appeared
the way more simple. It would as well allow to instantiate multiple
rabbit clusters constructed from prefix-based instances of rabbit nodes.

The complexity with DNS alias is what we have 1) a node name in CIB
(corosync cluster's crm_node -n), 2) a node name as we want it in rabbit
cluster (with some prefix), 3) the actual clustered rabbit node name in
the mnesia DB constructed from the name (2) with the rabbit@<...> prefix
added.

So, as we often compare those in the RA logic and assume (1) == (2), the
prefix-based solution would be more simple. Otherwise we shall introduce
some translate_name() function, which translates the name (1) into the
name (2), for example using DNS resolving, and fix all of the type (1),
(2), (3) names comparsions in the OCF RA. Which would end up in much
more changes to test and maintain.

[0] https://review.openstack.org/#/c/262535/8

> 
>>
>> On Dec 23, 2015 8:42 PM, "Andrew Maksimov" > > 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
>> mailto:kgala...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] RabbitMQ in dedicated network

2015-12-28 Thread Andrew Woodward 
On Mon, Dec 28, 2015 at 1:13 AM Bogdan Dobrelya 
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"  > > 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
> > mailto:kgala...@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-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> > <
> http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 

--

Andrew Woodward

Mirantis

Fuel Community Ambassador

Ceph Community
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] RabbitMQ in dedicated network

2015-12-28 Thread Bogdan Dobrelya 
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"  > 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
> mailto:kgala...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] RabbitMQ in dedicated network

2015-12-23 Thread Vladimir Kuklin 
Kyrylo

One comment here. Hostname on the nodes resolves to its management network
as it is put into /etc/hosts file during the deployment.

On Wed, Dec 23, 2015 at 9:27 PM, Alexey Lebedeff 
wrote:

>
> When long node names are enabled (controlled by RABBITMQ_USE_LONGNAME
> environment variable), you could actually use IP-address as a node name.
>
> Matthew Mosesohn writes:
>
> > 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)
> > On Dec 23, 2015 8:42 PM, "Andrew Maksimov" 
> 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 
> >> 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] RabbitMQ in dedicated network

2015-12-23 Thread Alexey Lebedeff 

When long node names are enabled (controlled by RABBITMQ_USE_LONGNAME
environment variable), you could actually use IP-address as a node name.

Matthew Mosesohn writes:

> 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)
> On Dec 23, 2015 8:42 PM, "Andrew Maksimov"  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 
>> 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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] RabbitMQ in dedicated network

2015-12-23 Thread Matthew Mosesohn 
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)
On Dec 23, 2015 8:42 PM, "Andrew Maksimov"  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 
> 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [fuel] RabbitMQ in dedicated network

2015-12-23 Thread Andrew Maksimov 
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 
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [fuel] RabbitMQ in dedicated network

2015-12-23 Thread Kyrylo Galanov 
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev