Re: [PATCH] move VTest installation to scripts/build-vtest.sh

[Илья Шипицин]

сб, 15 мая 2021 г. в 01:14, Илья Шипицин :

>
>
> сб, 15 мая 2021 г. в 00:56, Nicolas CARPi :
>
>> > I compared several times, git clone is faster
>> In my hands curl is the fastest option compared to git clone.
>>
>
> ok, I'll make more comparison tomorrow
>


I attached a patch that uses "curl". on a distance it seems to be faster
for 50%


>
>
>>
>> Wouldn't "git clone --depth 1" be a good option to consider here? It
>> avoids getting the full history.
>>
>> ~Nico
>>
>
From 7d933d88dc03782bab2985081bb9629d3a3389fd Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin 
Date: Sat, 15 May 2021 11:46:15 +0500
Subject: [PATCH] CI: introduce scripts/build-vtest.sh for installing VTest

we install VTest for all CI systems, let us unify instalation
---
 .cirrus.yml|  3 +--
 .github/workflows/openssl-nodeprecated.yml |  3 +--
 .github/workflows/vtest.yml|  8 ++--
 .travis.yml|  4 +---
 scripts/build-vtest.sh | 10 ++
 5 files changed, 15 insertions(+), 13 deletions(-)
 create mode 100755 scripts/build-vtest.sh

diff --git a/.cirrus.yml b/.cirrus.yml
index fdabfdcdd..9b83e6169 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -6,8 +6,7 @@ FreeBSD_task:
   install_script:
 - pkg update -f && pkg upgrade -y && pkg install -y openssl git gmake lua53 socat pcre
   script:
-- git clone https://github.com/VTest/VTest.git ../vtest
-- make -C ../vtest
+- scripts/build-vtest.sh
 - gmake CC=clang V=1 ERR=1 TARGET=freebsd USE_ZLIB=1 USE_PCRE=1 USE_OPENSSL=1 USE_LUA=1 LUA_INC=/usr/local/include/lua53 LUA_LIB=/usr/local/lib LUA_LIB_NAME=lua-5.3
 - ./haproxy -vv
 - ldd haproxy
diff --git a/.github/workflows/openssl-nodeprecated.yml b/.github/workflows/openssl-nodeprecated.yml
index b853fe233..6833911e4 100644
--- a/.github/workflows/openssl-nodeprecated.yml
+++ b/.github/workflows/openssl-nodeprecated.yml
@@ -23,8 +23,7 @@ jobs:
 - uses: actions/checkout@v1
 - name: prepare VTest
   run: |
-git clone https://github.com/VTest/VTest.git ../vtest
-make -C ../vtest FLAGS="-O2 -s -Wall"
+scripts/build-vtest.sh
 - name: build haproxy
   run: |
 make DEFINE="-DOPENSSL_API_COMPAT=0x1010L -DOPENSSL_NO_DEPRECATED" -j3 CC=gcc ERR=1 TARGET=linux-glibc USE_OPENSSL=1
diff --git a/.github/workflows/vtest.yml b/.github/workflows/vtest.yml
index cb52f27d6..f7f34d720 100644
--- a/.github/workflows/vtest.yml
+++ b/.github/workflows/vtest.yml
@@ -60,11 +60,7 @@ jobs:
 brew install lua
 - name: Install VTest
   run: |
-curl -fsSL https://github.com/vtest/VTest/archive/master.tar.gz -o VTest.tar.gz
-mkdir VTest
-tar xvf VTest.tar.gz -C VTest --strip-components=1
-make -C VTest -j$(nproc) FLAGS="-O2 -s -Wall"
-sudo install -m755 VTest/vtest /usr/local/bin/vtest
+scripts/build-vtest.sh
 - name: Install SSL ${{ matrix.ssl }}
   if: ${{ matrix.ssl && matrix.ssl != 'stock' }}
   run: env ${{ matrix.ssl }} scripts/build-ssl.sh
@@ -101,7 +97,7 @@ jobs:
 - name: Run VTest for HAProxy ${{ steps.show-version.outputs.version }}
   id: vtest
   # sudo is required, because macOS fails due to an open files limit.
-  run: sudo make reg-tests REGTESTS_TYPES=default,bug,devel
+  run: sudo make reg-tests VTEST_PROGRAM=../vtest/vtest REGTESTS_TYPES=default,bug,devel
 - name: Show results
   if: ${{ failure() }}
   # The chmod / sudo is necessary due to the `sudo` while running the tests.
diff --git a/.travis.yml b/.travis.yml
index 1aa415aa8..3083e302c 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -38,9 +38,7 @@ matrix:
 if: type == cron
 
 install:
-  - git clone https://github.com/VTest/VTest.git ../vtest
-  # Special flags due to: https://github.com/vtest/VTest/issues/12
-  - make -C ../vtest FLAGS="-O2 -s -Wall"
+  - scripts/build-vtest.sh
 
 script:
   - make -j$(nproc) ERR=1 TARGET=linux-glibc CC=$CC DEBUG=-DDEBUG_STRICT=1 $FLAGS
diff --git a/scripts/build-vtest.sh b/scripts/build-vtest.sh
new file mode 100755
index 0..4db35d6ee
--- /dev/null
+++ b/scripts/build-vtest.sh
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+set -eux
+
+curl -fsSL https://github.com/vtest/VTest/archive/master.tar.gz -o VTest.tar.gz
+mkdir ../vtest
+tar xvf VTest.tar.gz -C ../vtest --strip-components=1
+# Special flags due to: https://github.com/vtest/VTest/issues/12
+make -C ../vtest FLAGS="-O2 -s -Wall"
+
-- 
2.31.1

Re: [PATCH] move VTest installation to scripts/build-vtest.sh

[Илья Шипицин]

сб, 15 мая 2021 г. в 00:56, Nicolas CARPi :

> > I compared several times, git clone is faster
> In my hands curl is the fastest option compared to git clone.
>

ok, I'll make more comparison tomorrow


>
> Wouldn't "git clone --depth 1" be a good option to consider here? It
> avoids getting the full history.
>
> ~Nico
>

Re: [PATCH] move VTest installation to scripts/build-vtest.sh

[Nicolas CARPi]

> I compared several times, git clone is faster
In my hands curl is the fastest option compared to git clone.

Wouldn't "git clone --depth 1" be a good option to consider here? It
avoids getting the full history.

~Nico

Re: [PATCH] move VTest installation to scripts/build-vtest.sh

[Илья Шипицин]

сб, 15 мая 2021 г. в 00:20, Tim Düsterhus :

> Ilya,
>
> On 5/14/21 9:02 PM, Илья Шипицин wrote:
> > let us unify VTest installation magic.
>
> I disagree with using 'git clone' here, cloning the repository with full
> history is wasteful. Please use the tarball approach from vtest.yml
>

I think, if we download from github releases, indeed those are
pre-packaged. Master seems to be created on the fly.
I compared several times, git clone is faster

[ilia@localhost temp]$ time git clone https://github.com/VTest/VTest.git
Cloning into 'VTest'...
remote: Enumerating objects: 1072, done.
remote: Counting objects: 100% (320/320), done.
remote: Compressing objects: 100% (171/171), done.
remote: Total 1072 (delta 213), reused 241 (delta 149), pack-reused 752
Receiving objects: 100% (1072/1072), 588.23 KiB | 223.00 KiB/s, done.
Resolving deltas: 100% (740/740), done.

real 0m6.045s
user 0m0.287s
sys 0m0.087s
[ilia@localhost temp]$ time curl -fsSL
https://github.com/vtest/VTest/archive/master.tar.gz -o VTest.tar.gz

real 0m8.185s
user 0m0.071s
sys 0m0.020s
[ilia@localhost temp]$

I can swich to "curl" ifthere's more justification of that



>
> Best regards
> Tim Düsterhus
>

Re: adding Coverity badge to some visible place

[Tim Düsterhus]

Daniel,
Ilya,

On 5/14/21 5:45 PM, Daniel Corbett wrote:

I would like to improve code quality visibility.
what if we convert README --> README.md and put Coverity badge there ?



Funny, I had a similar thought earlier today about having a README.md.

I would like to help improve it from a visual perspective.

+1 from me and very interested!



Yes, I believe using a README.md to benefit from the better formatting 
for the repository's landing page is useful.


But please don't add a large number of stupid badges there. They do not 
benefit the end user. Especially Coverity with all the false positives 
is going to be absolutely useless and distract from more important stuff.


Best regards
Tim Düsterhus

Re: [PATCH] move VTest installation to scripts/build-vtest.sh

[Tim Düsterhus]

Ilya,

On 5/14/21 9:02 PM, Илья Шипицин wrote:

let us unify VTest installation magic.


I disagree with using 'git clone' here, cloning the repository with full 
history is wasteful. Please use the tarball approach from vtest.yml


Best regards
Tim Düsterhus

[PATCH] move VTest installation to scripts/build-vtest.sh

[Илья Шипицин]

Hello,

let us unify VTest installation magic.

Ilya
From 9f85fe25ad9ee6bf753311a44a5089a6ee2096c9 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin 
Date: Fri, 14 May 2021 23:59:35 +0500
Subject: [PATCH] CI: introduce scripts/build-vtest.sh for installing VTest

we install VTest for all CI systems, let us unify instalation
---
 .cirrus.yml| 3 +--
 .github/workflows/openssl-nodeprecated.yml | 3 +--
 .github/workflows/vtest.yml| 8 ++--
 .travis.yml| 4 +---
 scripts/build-vtest.sh | 8 
 5 files changed, 13 insertions(+), 13 deletions(-)
 create mode 100755 scripts/build-vtest.sh

diff --git a/.cirrus.yml b/.cirrus.yml
index fdabfdcdd..9b83e6169 100644
--- a/.cirrus.yml
+++ b/.cirrus.yml
@@ -6,8 +6,7 @@ FreeBSD_task:
   install_script:
 - pkg update -f && pkg upgrade -y && pkg install -y openssl git gmake lua53 socat pcre
   script:
-- git clone https://github.com/VTest/VTest.git ../vtest
-- make -C ../vtest
+- scripts/build-vtest.sh
 - gmake CC=clang V=1 ERR=1 TARGET=freebsd USE_ZLIB=1 USE_PCRE=1 USE_OPENSSL=1 USE_LUA=1 LUA_INC=/usr/local/include/lua53 LUA_LIB=/usr/local/lib LUA_LIB_NAME=lua-5.3
 - ./haproxy -vv
 - ldd haproxy
diff --git a/.github/workflows/openssl-nodeprecated.yml b/.github/workflows/openssl-nodeprecated.yml
index b853fe233..6833911e4 100644
--- a/.github/workflows/openssl-nodeprecated.yml
+++ b/.github/workflows/openssl-nodeprecated.yml
@@ -23,8 +23,7 @@ jobs:
 - uses: actions/checkout@v1
 - name: prepare VTest
   run: |
-git clone https://github.com/VTest/VTest.git ../vtest
-make -C ../vtest FLAGS="-O2 -s -Wall"
+scripts/build-vtest.sh
 - name: build haproxy
   run: |
 make DEFINE="-DOPENSSL_API_COMPAT=0x1010L -DOPENSSL_NO_DEPRECATED" -j3 CC=gcc ERR=1 TARGET=linux-glibc USE_OPENSSL=1
diff --git a/.github/workflows/vtest.yml b/.github/workflows/vtest.yml
index cb52f27d6..f7f34d720 100644
--- a/.github/workflows/vtest.yml
+++ b/.github/workflows/vtest.yml
@@ -60,11 +60,7 @@ jobs:
 brew install lua
 - name: Install VTest
   run: |
-curl -fsSL https://github.com/vtest/VTest/archive/master.tar.gz -o VTest.tar.gz
-mkdir VTest
-tar xvf VTest.tar.gz -C VTest --strip-components=1
-make -C VTest -j$(nproc) FLAGS="-O2 -s -Wall"
-sudo install -m755 VTest/vtest /usr/local/bin/vtest
+scripts/build-vtest.sh
 - name: Install SSL ${{ matrix.ssl }}
   if: ${{ matrix.ssl && matrix.ssl != 'stock' }}
   run: env ${{ matrix.ssl }} scripts/build-ssl.sh
@@ -101,7 +97,7 @@ jobs:
 - name: Run VTest for HAProxy ${{ steps.show-version.outputs.version }}
   id: vtest
   # sudo is required, because macOS fails due to an open files limit.
-  run: sudo make reg-tests REGTESTS_TYPES=default,bug,devel
+  run: sudo make reg-tests VTEST_PROGRAM=../vtest/vtest REGTESTS_TYPES=default,bug,devel
 - name: Show results
   if: ${{ failure() }}
   # The chmod / sudo is necessary due to the `sudo` while running the tests.
diff --git a/.travis.yml b/.travis.yml
index 1aa415aa8..3083e302c 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -38,9 +38,7 @@ matrix:
 if: type == cron
 
 install:
-  - git clone https://github.com/VTest/VTest.git ../vtest
-  # Special flags due to: https://github.com/vtest/VTest/issues/12
-  - make -C ../vtest FLAGS="-O2 -s -Wall"
+  - scripts/build-vtest.sh
 
 script:
   - make -j$(nproc) ERR=1 TARGET=linux-glibc CC=$CC DEBUG=-DDEBUG_STRICT=1 $FLAGS
diff --git a/scripts/build-vtest.sh b/scripts/build-vtest.sh
new file mode 100755
index 0..6a974951e
--- /dev/null
+++ b/scripts/build-vtest.sh
@@ -0,0 +1,8 @@
+#!/bin/sh
+
+set -eux
+
+git clone https://github.com/VTest/VTest.git ../vtest
+# Special flags due to: https://github.com/vtest/VTest/issues/12
+make -C ../vtest FLAGS="-O2 -s -Wall"
+
-- 
2.31.1

Re: adding Coverity badge to some visible place

[Илья Шипицин]

some tools (e.g. Coverity, Travis-CI) are not attached to commits directly.
travis runs once a week, badge would be nice as well

пт, 14 мая 2021 г. в 20:45, Daniel Corbett :

> Hello Ilya,
>
> > From: Илья Шипицин 
> > Sent: Friday, May 14, 2021 11:10 AM
> > To: HAProxy 
> > Subject: adding Coverity badge to some visible place
>
> > Hello,
> >
> > I would like to improve code quality visibility.
> > what if we convert README --> README.md and put Coverity badge there ?
> >
>
> Funny, I had a similar thought earlier today about having a README.md.
>
> I would like to help improve it from a visual perspective.
>
> +1 from me and very interested!
>
> Thanks,
> -- Daniel
>
>

RE: adding Coverity badge to some visible place

[Daniel Corbett]

Hello Ilya,

> From: Илья Шипицин  
> Sent: Friday, May 14, 2021 11:10 AM
> To: HAProxy 
> Subject: adding Coverity badge to some visible place

> Hello,
> 
> I would like to improve code quality visibility.
> what if we convert README --> README.md and put Coverity badge there ?
>

Funny, I had a similar thought earlier today about having a README.md.

I would like to help improve it from a visual perspective.

+1 from me and very interested!

Thanks,
-- Daniel

adding Coverity badge to some visible place

[Илья Шипицин]

Hello,

I would like to improve code quality visibility.
what if we convert README --> README.md and put Coverity badge there ?

Ilya

Re: haproxy hung with CPU usage at 100% Heeeelp, please!!!

[Lukas Tribus]

The first thing I'd try is to disable multithreading (by putting
nbthread 1 in the global section of the configuration), so if that
helps.


Lukas

haproxy hung with CPU usage at 100% Heeeelp, please!!!

[Oriol Magrane]

Hi all,

we need help: after upgrading the OS of an haproxy server of ours to debian
buster and getting haproxy upgraded to the OS’ package 1.8.19-1 version we
started noticing eventual hangs of the process where it gets stuck at 100%
CPU usage and it stops accepting connections of any kind (front-end HTTP
connections, unix socket or TCP API queries or HTTP statistics retrievals).

These hangs happen only from time to time (quite randomly, it may take 10
minutes or several hours after starting haproxy), but we have observed they
are always triggered by a “set maxconn server” command sent via API while
haproxy is busy processing normal HTTP requests. (In order to keep some
backends capacity up-to-date we have a cron that issues a batch of between
30 to 40 of these commands once per minute to haproxy’s API).

We have been unable to establish any relation between the backend, server
and maxconn values of the ‘set maxconn server’ command that caused a hang
(they seem to differ on every occasion), and we have been unable to relate
it to the haproxy workload at that given time either.

We’ve also tried by source-compiling in the target machine a more recent
version of the 1.8 series (1.8.29) too, but to no avail: the problem
persists.

The only thing we seem to have been able to identify is where in the code
the process gets stuck: we attached a gdb to the haproxy process and let it
run freely, feeding it with regular workload and the usual API-based
maxconn server updates, until it hung. Interrupting the execution, and
asking the debugger a backtrace resulted in this:

^C

Program received signal SIGINT, Interrupt.

0x563d70c8613a in process_srv_queue (s=s@entry=0x563d70dd1960) at
src/queue.c:177

177 HA_SPIN_LOCK(SERVER_LOCK, &s->lock);

(gdb) bt full

#0  0x563d70c8613a in process_srv_queue (s=s@entry=0x563d70dd1960) at
src/queue.c:177

p = 0x563d70dcf330

maxconn = 

remote = 0

#1  0x563d70beda0f in server_parse_maxconn_change_request
(maxconn_str=, sv=0x563d70dd1960) at src/server.c:1269

v = 

end = 

v = 

end = 

#2  server_parse_maxconn_change_request (sv=0x563d70dd1960,
maxconn_str=) at src/server.c:1247

v = 

end = 0x563d70d69603 ""

#3  0x563d70bf2db2 in cli_parse_set_maxconn_server (private=, appctx=0x563d7143ff30, args=0x7ffd15cb9d20) at src/server.c:4295

sv = 0x563d70dd1960

warning = 

sv = 

warning = 

__pl_r = 

__pl_l = 

ret = 

#4  cli_parse_set_maxconn_server (args=0x7ffd15cb9d20,
appctx=0x563d7143ff30, private=) at src/server.c:4281

sv = 

warning = 

__pl_r = 

__pl_l = 

ret = 

#5  0x563d70c4e5df in cli_parse_request
(appctx=appctx@entry=0x563d7143ff30,
line=0x563d70d69603 "") at src/cli.c:479

args = {0x563d70d695c0 "set", 0x563d70d695c4 "maxconn",
0x563d70d695cc "server", 0x563d70d695d3 "group_b_remote_backend",
0x563d70d69601 "19", 0x563d70d69603 "" }

kw = 

arg = 

i = 

j = 

#6  0x563d70c4ebde in cli_io_handler (appctx=0x563d7143ff30) at
src/cli.c:622

si = 0x563d714a6ba0

req = 0x563d714a6940

res = 0x563d714a6980

bind_conf = 

reql = 68

len = 

#7  0x563d70c8705e in applet_run_active () at src/applet.c:87

curr = 

next = 

si = 0x563d714a6ba0

applet_cur_queue = {n = 0x563d7143ff30, p = 0x563d7143ff30}

max_processed = 

#8  0x563d70c31600 in run_poll_loop () at src/haproxy.c:2563

next = 

exp = 

next = 

exp = 

#9  run_thread_poll_loop (data=) at src/haproxy.c:2598

ptif = 

ptdf = 

start_lock = 0

#10 0x563d70b8c6f9 in main (argc=, argv=)
at src/haproxy.c:3201

tids = 0x563d710bda60

threads = 0x563d710bda80

i = 

old_sig = {__val = {2048, 140724969120513, 140724969120352, 179,
94821886072224, 94821884909799, 94821886091488, 94821885435755,
140724969120255, 140724969120576, 140724969120271, 140724969120608,
206158430256, 140724969120576, 140724969120384, 7368483128895714304}}

blocked_sig = {__val = {1844674406710583, 18446744073709551615
}}

err = 

retry = 

limit = {rlim_cur = 16497, rlim_max = 16497}

errmsg =
"\000\000\000\000\000\000\000\000P\000\000\000\000\000\000\000\210\334\377\377\377\377\377\377\000\000\000\000\000\000\000\000\003\000\000\000\060",
'\000' , "[\000\000\000n\000\000\000|\000\000\000w",
'\000' ,
"\360\006\236\f\335\177\000\000@\274\235\f\335\177\000\000
\000\000"

pidfd = 


... so the server HA_SPIN_LOCK() in line 177 of queue.c seems to be the
culprit.



At this point, we don’t know what we can do in order to get rid of this
problem. We tried with the new haproxy series 2.x and the issue is still
there; the only difference is the haproxy process doesn’t hang, but it gets

HashiCorp

[Esther Andres]

Good day,

I hope you received my previous email? Any thoughts from you will be greatly 
appreciated.

Regards,
Esther Andres


From: Esther Andres

Date: Thursday, 13 May 2021

To: haproxy@formilux.org

Subject: HashiCorp


Good Day,



I would like to know you are interested in HashiCorp Users across a range of 
industries and geographic regions.



If yes we can move forward.



Who we are



We are a global database providing company .



Hope we get positive reply from your team.



Thanks
Esther Andres

Access List

Re: [ANNOUNCE] haproxy-2.4.0

[Willy Tarreau]

On Fri, May 14, 2021 at 02:23:21PM +0200, Tim Düsterhus wrote:
> Willy,
> 
> On 5/14/21 11:56 AM, Willy Tarreau wrote:
> > And of course there's all the invisible stuff being done on the internals
> > to improve the code, make it more extensible, more reliable or faster. I
> > think that's about it. If you contributed something that I missed here,
> > sorry for this, that's already a lot to figure out. Don't feel upset, and
> > just respond here to point it :-)
> 
> URI normalization is missing in your summary :-)

I'm absolutely certain I added it in my long list of notes, I must have
lost it in the middle of a deleted block, sorry about that :-/

> > As usual, I've been careful when uploading the new release and I would
> > not be surprised to see a 404 or two, so do not hesitate to report any
> > issue. Please be gentle for the doc, as it also requires some manual
> > post-release adaptations and will take a bit more time.
> 
> a) The table on haproxy.org is missing the 'Bugs' link for HAProxy 2.4.

Ah good catch, now fixed!

> b) Can you please add initial 'snapshot's for new development versions:
> https://www.haproxy.org/download/2.5/src/snapshot/? My haproxy-auth-request
> CI relies on the snapshots and I already added 2.5, thus failing the build:
> https://github.com/TimWolla/haproxy-auth-request/runs/2582881096

OK, now done and added to my release notes for next time.

Thanks!
Willy

Re: [ANNOUNCE] haproxy-2.4.0

[Tim Düsterhus]

Willy,

On 5/14/21 11:56 AM, Willy Tarreau wrote:

And of course there's all the invisible stuff being done on the internals
to improve the code, make it more extensible, more reliable or faster. I
think that's about it. If you contributed something that I missed here,
sorry for this, that's already a lot to figure out. Don't feel upset, and
just respond here to point it :-)


URI normalization is missing in your summary :-)


As usual, I've been careful when uploading the new release and I would
not be surprised to see a 404 or two, so do not hesitate to report any
issue. Please be gentle for the doc, as it also requires some manual
post-release adaptations and will take a bit more time.


a) The table on haproxy.org is missing the 'Bugs' link for HAProxy 2.4.
b) Can you please add initial 'snapshot's for new development versions: 
https://www.haproxy.org/download/2.5/src/snapshot/? My 
haproxy-auth-request CI relies on the snapshots and I already added 2.5, 
thus failing the build: 
https://github.com/TimWolla/haproxy-auth-request/runs/2582881096


Best regards
Tim Düsterhus

[ANNOUNCE] haproxy-2.4.0

[Willy Tarreau]

Hi,

HAProxy 2.4.0 was released on 2021/05/14. It added 34 new commits
after version 2.4-dev19. This completes 6 months of improvements and
cleanups split into 1687 commits from 36 participants. I'm pleased to
welcome these 7 new contributors who got their first commit merged
into 2.4, hoping they'll want to continue:

  Florian Apolloner, Jan Wagner, Maciej Zdeb, Maximilian Mader,
  Phil Scherer, Thayne McCombs, Evgeny Varnavskiy

And these 29 other ones who are not new as they already contributed
before 2.4:

  Adis Nezirovic, Aleksandar Lazic, Amaury Denoyelle, Baptiste Assmann
  Bertrand Jacquin, Christian Ruppert, Christopher Faulet,
  Daniel Corbett, David Carlier, Dragan Dosen, Emeric Brun, Eric Salama,
  Frédéric Lécaille, Gilchrist Dadaglo, Ilya Shipitsin, Jerome Magnin,
  Joao Morais, Julien Pivotto, Matthieu Guegan, Miroslav Zagorac,
  Moemen MHEDHBI, Olivier Houchard, Remi Tricot-Le Breton,
  Thierry Fournier, Tim Duesterhus, William Dauchy, William Lallemand,
  Willy Tarreau, Yves Lafon

It's really great to see more and more participation in multiple areas,
turning good ideas into usable features, and with increasing quality
overall. Let's continue like this, it's going into the right direction.

Speaking of quality, for the first time we really managed to enforce the
feature freeze, leading to most only harmless stuff getting merged past
that point. It allowed us to focus much better than before on regressions
and eliminate the usual last-minute bugs. This, combined with the work
done by Ilya and Tim on the CI, and with the continuously growing set of
regression tests, has significantly shortened the average lifetime of the
bugs (many of which not leaving the developer's computer anymore). And
this pays off: each and every -dev version among the 20 ones produced
was deployed on haproxy.org, and no single failure was observed since,
not even a crash, hang, leak, slow down or rendering issue. This makes
me think that 2.4 out of the box is probably more reliable than the
excellent 2.2 after 14 revisions. That's also why we release slightly
before the initially expected deadline, it almost seems there's nothing
left to be fixed! This proves that with some shared efforts it's possible
to improve, and I hope that we'll continue on this trend so that 2.5 gets
even better (yes, it's always possible).

This version brings a few fixes for bugs and build issues on top of -dev19,
very minor changes (addition of some ARM CPU targets in the Makefile to ease
portable builds, a few extra normalizers, a few example files, and a sorting
key for "show profiling"). Please see at the end of this message for the
details.

What's new in 2.4 compared to 2.3 ? Lots of cool stuff! The work was spread
on several fronts:
  - performance and latency: a lot of work was done on locking reduction,
bringing 2.4 a much lower latency than 2.3 had, and a higher scalability.
2.4 is NUMA-aware on Linux and will avoid binding to cross-socket cores
by default. Idle server-side connections are now reusable even when SNI,
proxy protocol or transparent proxy are used, saving costly round trips.
Lua now supports lock-free multi-threading. Idle frontend connections
will now be closed as soon as possible during reloads.

  - reliability: "strict-limits" is on by default, experimental features
are protected against accidental use from a copy-paste, a diagnostic
mode was added to report suspicious or uncommon constructs that could
be mistakes, new live debugging tools were added for better in-field
debugging. Backend idle connections will be closed before quitting
so that they don't consume source ports in TIME_WAIT.

  - management and integration: maps and ACLs now support atomic updates,
server-side SSL certificates can also be updated without reloading,
servers can be added/removed without reloading (still experimental),
more server settings can be edited at run time, global variables can
be listed/edited at run time, "defaults" section can now be named,
reused an inherited, line numbers and file names can be included in
any command, file paths can now be relative to the config file, some
new ".if/.elif/.else/.endif" config directives permit a smoother
transition between versions using a same config file (particularly
useful for automated rollbacks), 

  - interoperability / protocol support: WebSocket over HTTP/2 (RFC8441)
is now supported on both sides, regardless of the version on the other
side. The cache now supports the "Vary" header with a few commonly
used headers, including "Accept-encoding" which gets normalized for
optimal cache hit ratio. The Prometheus exporter got a significant
liftup, requires less tricks on the Prometheus side, and supports
listing only certain metrics for faster retrieval. Optional native
support for Opentracing was also integrated (via USE_OT=1). The DNS
resolvers now support talking to ser