SYMC: Kill Haproxy process does not automatically spawn a new haproxy

Bug #1424766 reported by Varun Lodaya
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R3.2
New
High
Yuvaraja Mariappan
R4.0
New
High
Yuvaraja Mariappan
R4.1
New
High
Yuvaraja Mariappan
R5.0
New
High
Yuvaraja Mariappan
Trunk
New
High
Yuvaraja Mariappan
OpenContrail
New
High
Yuvaraja Mariappan

Bug Description

I tried manually killing haproxy on hypervisor and see it it spawns a new haproxy somewhere else, but I don't see that happening. The database still points to the old active/standby instances which does not seem to be correct.

[ash2] varun_lodaya@b0d009ash2006:~$
[ash2] varun_lodaya@b0d009ash2006:~$ ps -ef | grep haproxy

nobody 28985 1 0 17:27 ? 00:00:00 haproxy -f /var/lib/contrail/loadbalancer/bbf5cf9a-f643-4a4e-9dd7-038818d5739e/etc/haproxy/haproxy.cfg -D -p /var/lib/contrail/loadbalancer/bbf5cf9a-f643-4a4e-9dd7-038818d5739e/etc/haproxy/haproxy.cfg.pid -sf 28970

[ash2] varun_lodaya@b0d009ash2006:~$ sudo kill -9 28985
[ash2] varun_lodaya@b0d009ash2006:~$

Same virtual_machine_back_refs even after killing haproxy on 1 node.

"virtual_machine_back_refs": [
            {
                "attr": null,
                "href": "http://localhost:9100/virtual-machine/779e583e-2c89-4747-a7ef-c0bf94ce4a8c",
                "to": [
                    "SDN__sdn__64f5f871-4ac9-4e3f-bf41-37f47c380016__1"
                ],
                "uuid": "779e583e-2c89-4747-a7ef-c0bf94ce4a8c"
            },
            {
                "attr": null,
                "href": "http://localhost:9100/virtual-machine/e2ca90ec-9653-4219-a94a-9c02a3584028",
                "to": [
                    "SDN__sdn__64f5f871-4ac9-4e3f-bf41-37f47c380016__2"
                ],
                "uuid": "e2ca90ec-9653-4219-a94a-9c02a3584028"
            }
        ]

Rudra Rugge (rrugge)
Changed in opencontrail:
assignee: nobody → Divakar Dharanalakota (ddivakar)
Revision history for this message
Édouard Thuleau (ethuleau) wrote :

That's an interesting issue.
Rudra Divakar, did you already exchanged on that problem?
I think that need to be discussing.

I saw the HAProxy process is configured by default to bind the stats API on all netns IPs [1] but I did not find any code that use it. That could be a way to perform health checks on the HAPproxy and probably to raise statistics to the collectors. But IMO we should though to restrict the access of that API to the vrouter for security reasons.

[1] https://github.com/Juniper/contrail-controller/blob/master/src/vnsw/agent/oper/loadbalancer_haproxy.cc#L80

Babu Shanmugam (anbu-p)
Changed in opencontrail:
assignee: Divakar Dharanalakota (ddivakar) → Babu Shanmugam (anbu-p)
Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : master

Review in progress for https://review.opencontrail.org/10407
Submitter: Babu Shanmugam (<email address hidden>)

Revision history for this message
OpenContrail Admin (ci-admin-f) wrote : [Review update] master

Review in progress for https://review.opencontrail.org/10407
Submitter: Babu Shanmugam (<email address hidden>)

summary: - Kill Haproxy process does not automatically spawn a new haproxy
+ SYMC: Kill Haproxy process does not automatically spawn a new haproxy
Changed in opencontrail:
importance: Undecided → High
tags: added: config provisioning
Jim Reilly (jpreilly)
tags: added: att-aic-contrail
Rudra Rugge (rrugge)
Changed in opencontrail:
assignee: Babu Shanmugam (anbu-p) → Yuvaraja Mariappan (ymariappan)
Rudra Rugge (rrugge)
no longer affects: juniperopenstack
Jim Reilly (jpreilly)
tags: added: blocker
Revision history for this message
Jim Reilly (jpreilly) wrote :

per Yuvaraja Mariappan

This needs some design changes and maybe alot of code changes as well.

Needs to be discussed within Juniper and it may be tough to make it in 3.2.10.0 time frame given the focus on 5.0 that is due to be released to ATT on 4/23

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.