[ClusterLabs] Can packmaker launch haproxy from new network namespace automatically?

[Hao QingFeng]

Hi Folks,

I am installing packmaker to manage the cluster of haproxy within 
openstack on ubuntu 16.04.

I met the problem that haproxy can't start listening for some services 
in vip because the related ports

were occupied by those native services which listened on 0.0.0.0.

I opened a bug to openstack team and a buddy told me that I should use 
pacemaker to run haproxy in

a separate network namespace.  I attached his description here(also in bug):

<<<

Fuel runs haproxy via pacemaker (not vis systemd/upstart) and pacemaker 
runs haproxy in a separate network namespace.

So haproxy does not cause any problems by listedning on 0.0.0.0 since 
it's listening in a separate network namespace.

You can see it via "ip netns ls" command and then "ip netns exec haproxy 
ip a".

Did you try to restart haproxy via systemd/upstart? If so then you could 
face this problem. You should use pacemaker to control haproxy service.

 >>>

Here is the bug link:

https://bugs.launchpad.net/openstack-manuals/+bug/1649902

Actually I did start haproxy with pacemaker but "ip netns ls" show 
nothing and haproxy can't bind some port like 9292 on vip .

I checked and found that openstack starts including this function from 
fuel 5.0(released in May, 2014).

But after I downloaded pacemaker's code, did a rough check, I couldn't 
find any related functions(keywords: ip netns, clone, CLONE_NEW...)

except in the test cases for neutron and ovs etc(if my understanding is 
correct).

I didn't see any related configuration item in "crm configure show" either.


So I would like just  to confirm that if pacemaker has such function to 
create a new network namespace

for haproxy(or other manged service) automatically to avoid such socket 
binding conflict?

If yes, how to configure it? If no such function, do you have any advice 
on how to solve the problem?

BTW, you can see the detailed configuration information in the bug link, 
if you need more, please let me know.

Thanks a lot!

Regards!

-- 

QingFeng Hao(Robin)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clusterlabs.org/pipermail/users/attachments/20161218/0252ecd4/attachment.html>