Bug 1560698 - In newton , neutron-lbaas adds --connection-limit value only in the frontend
Summary: In newton , neutron-lbaas adds --connection-limit value only in the frontend
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron-lbaas
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: z8
: 10.0 (Newton)
Assignee: Carlos Goncalves
QA Contact: Toni Freger
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-03-26 19:12 UTC by David Hill
Modified: 2022-08-16 09:59 UTC (History)
6 users (show)

Fixed In Version: openstack-neutron-lbaas-9.2.2-7.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-17 15:51:29 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-4993 0 None None None 2022-08-16 09:59:41 UTC
Red Hat Product Errata RHBA-2018:1603 0 None None None 2018-05-17 15:52:28 UTC

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


Note You need to log in before you can comment on or make changes to this bug.