Re: [ANNOUNCE] haproxy-2.3.0

2020-11-11 Thread Willy Tarreau
Hi Cyril!

On Wed, Nov 11, 2020 at 10:47:21PM +0100, Cyril Bonté wrote:
> I'm sad to not find enough time to contribute to haproxy. But well, at least
> I try to read mail subjects :-/
> With some delays, I've now pushed the documentation for 2.3 and 2.4-dev ;-)

Thank you!

Willy



Re: [ANNOUNCE] haproxy-2.3.0

2020-11-11 Thread Tim Düsterhus
Cyril,

Am 11.11.20 um 22:47 schrieb Cyril Bonté:
>> HAProxy 2.3.0 was released on 2020/11/05. It added 33 new commits after
>> version 2.3-dev9. I was right to wait a few more days before releasing,
>> we could spot two late regressions and fix them in time!
>> [...]
>>     Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/
> 
> I'm sad to not find enough time to contribute to haproxy. But well, at
> least I try to read mail subjects :-/
> With some delays, I've now pushed the documentation for 2.3 and 2.4-dev ;-)
> 

Would it be helpful giving the repository a new home in the 'haproxy'
organization [1] by moving the repository there? It would not be reliant
on you personally then and updating it could be included as part of the
regular release workflow (or even automated [1]). I'm not sure how
moving a repository affects GitHub pages, though.

Best regards
Tim Düsterhus

[1] https://github.com/haproxy/
[2] https://github.com/stefanzweifel/git-auto-commit-action



Re: [ANNOUNCE] haproxy-2.3.0

2020-11-11 Thread Cyril Bonté

Hi all !

Le 05/11/2020 à 19:20, Willy Tarreau a écrit :

Hi,

HAProxy 2.3.0 was released on 2020/11/05. It added 33 new commits after
version 2.3-dev9. I was right to wait a few more days before releasing,
we could spot two late regressions and fix them in time!
[...]
Cyril's HTML doc : http://cbonte.github.io/haproxy-dconv/


I'm sad to not find enough time to contribute to haproxy. But well, at 
least I try to read mail subjects :-/

With some delays, I've now pushed the documentation for 2.3 and 2.4-dev ;-)

--
Cyril Bonté



Re: [ANNOUNCE] haproxy-2.3.0

2020-11-06 Thread William Lallemand
On Thu, Nov 05, 2020 at 07:20:46PM +0100, Willy Tarreau wrote:
> Hi,
> 
> HAProxy 2.3.0 was released on 2020/11/05. It added 33 new commits after
> version 2.3-dev9. I was right to wait a few more days before releasing,
> we could spot two late regressions and fix them in time!
> 

Hi,

The crt-list support of this version is partly broken, lines are
silently ignored if they uses a certificate which was already loaded.

A fix was pushed today in the git:

https://git.haproxy.org/?p=haproxy-2.3.git;a=commit;h=689d981541a4805760acd6a2ba1433dc3d3534b1

Distribution maintainers should consider this one if they didn't emit
the 2.3.0 yet. 

We'll probably make a 2.3.1 release at the end of next week.

Sorry for the mess!

-- 
William Lallemand



[ANNOUNCE] haproxy-2.3.0

2020-11-05 Thread Willy Tarreau
Hi,

HAProxy 2.3.0 was released on 2020/11/05. It added 33 new commits after
version 2.3-dev9. I was right to wait a few more days before releasing,
we could spot two late regressions and fix them in time!

This time we're on schedule and that's great. It's also one of the benefits
of working more on features than for a target version. We could start with
some accumulated stuff pending in -next (which we'll do again by the way)
and focus more on features at the beginning of the cycle and more on fixes
and cleanups at the end.

Most of the changes in this version are not user-visible, as frustrating
as this can be, as they're more low-level stuff to prepare the ground to
accept new features for 2.4. With this said, I can still cite a few nice
new features which were already mentioned as they were merged but I know
not everyone reads development announces:

  - syslog forwarding / load balancing: we can now receive UDP/TCP syslog
and forward the messages to any set of servers over UDP/TCP/unix etc,
and even transcode the RFC3164/5424 formats as needed. A typical use
case is to receive log from your infrastructure and load-balance them
to a two-servers farm while keeping a local copy to a 3rd server. It
makes use of the existing logging infrastructure and as such, benefits
from its facilities. Check "log-forward" in the doc for more info.

  - the stats engine was improved to allow "modules" to register and provide
their own counters. Actually these modules are all of the non-core stuff
that was hard to integrate with the stats. Muxes are such an example,
SSL is another one, more will come soon (actually I'm seeing that the
SSL part was not merged in time for 2.3 but we may backport it later
if needed). The problem was to add optional counters without breaking
existing tools, and for this the stats output is cut in two parts, the
fixed metrics first, a column named "-" and dynamic metrics which may
change with your version, build options, etc. On the HTML stats page,
these are optionally reported when "stats show-modules" is specified,
in which case a new column is added with links to the relevant modules
and their respective stats. The output isn't as pretty there since
these stats by definition are of any type. But they're properly typed
and available to all outputs, including Prometheus.

  - the second improvement in the stats is that they now support "domains",
which allow modules to register stats for everything not a proxy or a
server. The DNS stats that were available in "show resolvers" are now
available in a generic way under "show stat domain dns". We can expect
that peers, SPOE etc which do not directly interact with proxies will
appear there in the near future.

  - another improvement to the stats is that it's now possible not to list
servers that are in maintenance, typically because they were reserved
using a server-template. Users with huge configs had to consume gigabytes
of data because of this. This change was really trivial, and if this is
something you're suffering from in an LTS version, let me know, maybe
I'll accept to backport it to 2.2. Maybe.

  - the cache is now able to respond "304 not modified" to conditional
requests instead of returning the full object. This will not change the
cache hit ratio but could slightly lower the amount of data sent over
the wire when the client already has an up-to-date content.

  - in "http-reuse safe" mode (the default one), we don't merge multiple
clients' requests anymore. The reason behind this is to avoid the
head-of-line blocking that results from merging multiple client
connections into a same server connection when one of these clients
is slow. This may result in slightly higher H2 connection counts on
your servers if using H2 on the backend at high request rates, but
in lower and stable response times for your users.

  - backend connections using a constant "sni()" expression will now
support being reused. In the past they were closed, but some users
have fixed strings there and there was no reason for not supporting
them in an optimal way.

  - an option was added to decide how to match SSL file name extensions
(either appending ".key" or replacing ".crt" with ".key"), because it
used to be unconventional for some users to have "foo.crt.key" next
to "foo.crt".

  - some minor adjustments were made to the non-deterministic LB algos to
improve the resistance and ability to gracefully recover from bad
situations (e.g. huge queues after a temporary network outage). They
will avoid searching for a server if it's known that all are full. In
addition, leastconn will now consider the server's queue length in
addition to the connection count and will accept to append directly
into the server's queue if that's considered better than any other