Congrats on the release, Willy & the rest of the team!

I've been following along the torturous road, and I'm happy to see all the 
issues resolved and the excellent results. Personally, I'm excited about the 
performance gains. I'll deploy this soon on our network.

To dig up an old discussion—I took a look at better support for SRV records 
(using the priority field as backup/non-backup, etc.) a few weeks ago, but 
determined it didn't make sense in our use case. The issue is 0 weighted 
servers are considerably less useful to us since they aren't ever used, even in 
the condition where every other server is down.

That raises the next question: is the idea of server groups (with the ability 
for a request to try group 1, then group 2, etc. on retries) in the development 
plans at some point? Would that be something I could tinker as a longer term 


Luke Seelenbinder
Stadia Maps | Founder

> On 7 Jul 2020, at 19:20, Willy Tarreau <> wrote:
> Hi,
> HAProxy 2.2.0 was released on 2020/07/07. It added 24 new commits
> after version 2.2-dev12.
> There were very few last-minute changes since dev12, just as I hoped,
> that's pretty fine.
> We're late by about 1 month compared to the initial planning, which is
> not terrible and should be seen instead as an investment on the debugging
> cycle since almost only bug fixes were merged during that period. In the
> end you get a better version later.
> While I was initially worried that this version didn't seem to contain
> any outstanding changes, looking back in the mirror tells be it's another
> awesome one instead:
>  - dynamic content emission:
>     - "http-request return" directive to build dynamic responses ;
>     - rewrite of headers (including our own) after the response ;
>     - dynamic error files (errorfiles can be used as templates to
>       deliver personalized pages)
>  - further improvements to TLS runtime certificates management:
>     - insertion of new certificates
>     - split of key and cert
>     - manipulation and creation of crt-lists
>     - even directories can be handled
>    And by the way now TLSv1.2 is set as the default minimum version.
>  - significant reduction of server-side resources by sharing idle
>    connection pools between all threads ; till 2.1 if you had 64 threads,
>    each of them had its own connections, so the reuse rate was lower, and
>    the idle connection count was very high. This is not the case anymore.
>  - health-checks were rewritten to all rely on tcp-check rules behind the
>    curtains. This allowed to get rid of all the dirt we had accumulate over
>    18 years and to write extensible checks. New ones are much easier to add.
>    In addition we now have http-checks which support header and body
>    addition, and which pass through muxes (HTTP/1 and HTTP/2).
>  - ring buffer creation with ability to forward any event to any log server
>    including over TCP. This means that it's now possible to log over a TCP
>    syslog server, and that adding new protocols should be fairly easy.
>  - further refined and improved debugging (symbols in panic dumps, malloc
>    debugging, more activity counters)
>  - the default security was improved. For example fork() is forbidden by
>    default, which will block against any potential code execution (and
>    will also block external checks by default unless explicitly unblocked).
>  - new performance improvements in the scheduler and I/O layers, reducing
>    the cost of I/O processing and overall latency. I've known from private
>    discussions that some noticed tremendous gains there.
> I'm pretty sure there are many other things but I don't remember, I'm
> looking at my notes. I'm aware that HaproxyTech will soon post an in-depth
> review on the blog so just have a look there for all the details.
> (edit: it's already there: 
> ).
> There are three things I noted during the development of this version.
> The first one is that with the myriad of new tools we're using to help
> users and improve our code quality (discourse, travis, cirrus, oss-fuzz,
> mailing-list etc), some people really found their role in the project and
> are becoming more autonomous. This definitely scales much better and helps
> me spend less time on things that are not directly connected to my code
> activities, so thank you very much for this (Lukas, Tim, Ilya, Cyril).
> The second one is that this is the first version that has been tortured
> in production long before the release. And when I'm saying "tortured", I
> really mean it, because several of us were suffering as well. But it
> allowed to address very serious issues that would have been a nightmare
> to debug and fix post-release. For this I really want to publicly thank
> William Dauchy for all his work and involvement on this, and for all the
> very detailed reports he's sent us. For me this is the proof that running
> code early on very limited traffic is enough to catch unacceptable bugs
> that will not hit you later. And this pays off because he will be able to
> deploy 2.2 soon without sweating. Others might face bugs that were not in
> the perimeter he tested, hehe :-) I really encourage anyone who can to do
> this. I know it's not easy and can be risky, but with some organization
> and good prod automation it's possible and is great. What's nice with
> reporting bugs during development is that you have a safe version to roll
> back to and it can take the time it takes to fix the bug, it's not a
> problem! Please think about it and what it would imply for you to adopt
> such a model, it's a real time saver and risk saver for your production.
> The last one is that we started to use the -next branch to queue some
> pending work (that was already merged) and that the principle of finishing
> one version while we're starting to queue some work for the next one is
> well accepted and will help really us. I'd like this to continue and grow
> in importance.
> Enough talking, now's time to download and update, and for me to leave to
> have dinner :-)
> Please find the usual URLs below :
>   Site index       :
>   Discourse        :
>   Slack channel    :
>   Issue tracker    :
>   Sources          :
>   Git repository   :
>   Git Web browsing :
>   Changelog        :
>   Cyril's HTML doc :
>   Blog article     :
> Willy
> ---
> Complete changelog :
> Christopher Faulet (9):
>      MINOR: log: Remove unused case statement during the log-format string 
> parsing
>      BUG/MINOR: mux-h1: Fix the splicing in TUNNEL mode
>      BUG/MINOR: mux-h1: Don't read data from a pipe if the mux is unable to 
> receive
>      BUG/MINOR: mux-h1: Disable splicing only if input data was processed
>      BUG/MEDIUM: mux-h1: Disable splicing for the conn-stream if read0 is 
> received
>      MINOR: mux-h1: Improve traces about the splicing
>      BUG/MINOR: backend: Remove CO_FL_SESS_IDLE if a client remains on the 
> last server
>      BUG/MEDIUM: connection: Don't consider new private connections as 
> available
>      BUG/MINOR: connection: See new connection as available only on reuse 
> always
> Daniel Corbett (1):
>      DOC: configuration: various typo fixes
> Ilya Shipitsin (1):
>      CLEANUP: assorted typo fixes in the code and comments
> William Lallemand (4):
>      WIP/MINOR: ssl: add sample fetches for keylog in frontend
>      DOC: fix tune.ssl.keylog sample fetches array
>      BUG/MINOR: ssl: check conn in keylog sample fetch
>      CLEANUP: ssl: remove unrelevant comment in smp_fetch_ssl_x_keylog()
> Willy Tarreau (9):
>      BUILD: mux-h2: fix typo breaking build when using DEBUG_LOCK
>      CLEANUP: makefile: update the outdated list of DEBUG_xxx options
>      BUILD: tools: make resolve_sym_name() return a const
>      CLEANUP: auth: fix useless self-include of auth-t.h
>      BUILD: tree-wide: cast arguments to tolower/toupper to unsigned char
>      DOC: configuration: remove obsolete mentions of H2 being converted to 
> HTTP/1.x
>      DOC: update INSTALL with new compiler versions
>      DOC: minor update to coding style file
>      MINOR: version: mention that it's an LTS release now
> ---

Reply via email to