Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1560698

Summary:	In newton , neutron-lbaas adds --connection-limit value only in the frontend
Product:	Red Hat OpenStack	Reporter:	David Hill <dhill>
Component:	openstack-neutron-lbaas	Assignee:	Carlos Goncalves <cgoncalves>
Status:	CLOSED ERRATA	QA Contact:	Toni Freger <tfreger>
Severity:	high	Docs Contact:
Priority:	high
Version:	10.0 (Newton)	CC:	amuller, apevec, cgoncalves, dhill, lhh, nyechiel
Target Milestone:	z8	Keywords:	Triaged, ZStream
Target Release:	10.0 (Newton)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openstack-neutron-lbaas-9.2.2-7.el7ost	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-05-17 15:51:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Hill 2018-03-26 19:12:16 UTC

Description of problem:
In newton (RHOSP10), neutron-lbaas adds --connection-limit value only in the frontend instead of the frontend and backend/global and this has for effect that even if we set --connection-limit to 4000, we'll never go higher because the backend default limit is hardcoded to 2000 in haproxy.   This might be fixed in ocata with the following commit :
c7c77b33ba02b64ffa887bb9b837be5e8a3c22ef

Version-Release number of selected component (if applicable):
Newton / RHOSP 10

How reproducible:
Always

Steps to Reproduce:
1. Create a loadbalancer with --connection-limit 4000
2. Create 2001 connections
3.

Actual results:
Never goes above 2000

Expected results:
We should be able to go above 2000

Additional info:

Comment 1 David Hill 2018-03-26 19:18:58 UTC

--- a/neutron_lbaas/drivers/haproxy/templates/haproxy.loadbalancer.j2
+++ b/neutron_lbaas/drivers/haproxy/templates/haproxy.loadbalancer.j2
@@ -17,7 +17,6 @@
 {% set loadbalancer_name = loadbalancer.name %}
 {% set usergroup = user_group %}
 {% set sock_path = stats_sock %}
-{% set connection_limit = loadbalancer.connection_limit %}
 
 {% block proxies %}
 {% from 'haproxy_proxies.j2' import frontend_macro as frontend_macro, backend_macro%}
diff --git a/neutron_lbaas/drivers/haproxy/templates/haproxy_base.j2 b/neutron_lbaas/drivers/haproxy/templates/haproxy_base.j2
index 830580140..e405c959b 100644
--- a/neutron_lbaas/drivers/haproxy/templates/haproxy_base.j2
+++ b/neutron_lbaas/drivers/haproxy/templates/haproxy_base.j2
@@ -20,7 +20,6 @@ global
     group {{ usergroup }}
     log /dev/log local0
     log /dev/log local1 notice
-    maxconn {{ connection_limit }}
     stats socket {{ sock_path }} mode 0666 level user
 
 defaults

Comment 2 Carlos Goncalves 2018-03-27 11:42:15 UTC

Do you meant to say commit a792d8906c6c39a1097e9c8c0ab9fb0ce5aedbe3 (https://github.com/openstack/neutron-lbaas/commit/a792d8906c6c39a1097e9c8c0ab9fb0ce5aedbe3)?

Comment 3 David Hill 2018-03-29 20:18:43 UTC

Well yes.  It looks like we're actually only setting maxconn on the frontend so we're still limited by the global value of 2000.   We manually modified the jinja files to add a hardcoded value of 10000 in global and we can now reach 10000 simultaneous opened connection.

Comment 4 Carlos Goncalves 2018-04-04 10:48:34 UTC

With the backported patch (commit a792d8906c6c39a1097e9c8c0ab9fb0ce5aedbe3), the global connection limit will now be the sum of the connection limit on each listener defaulting to 2000 for each listener when connection limit is not specified. See https://github.com/openstack/neutron-lbaas/commit/a792d8906c6c39a1097e9c8c0ab9fb0ce5aedbe3#diff-e31d7db07cd1b718dfe390ef3c7fa046R267

Is there anything else missing?

Comment 5 David Hill 2018-04-04 13:12:33 UTC

This looks fine but this will be validated by QA if it works as expected.   The customer and I have simply added the same value in global as the frontends as a test and it worked as expected.   Maybe we can merge this and provide a test package to the customer and he'll be more than happy to test something "official" :)

Comment 14 errata-xmlrpc 2018-05-17 15:51:29 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:1603