Hi,
HAProxy 3.0-dev9 was released on 2024/04/27. It added 84 new commits
after version 3.0-dev8.
Less bug fixes this time and more merges. Most bug fixes were related to the
recent applet improvements and in peers.
Here's what's new:
- Following the previous series of fixes about the locking mechanism
of peers, it appeared there were some flaws. First, learning step
was not properly handled for the local peer, during a reload. Then
some operations performed by the peer applets and that had to be
acknowledged by the sync task were not blocking. It also appeared
the code was not obvious and hard to maintain. So a code cleanup /
reorganisation was performed to improve the situation.
- Add initial support for json, cbor(hex), and cbor(bin) encoding for
logformat expressions. This is achieved by using '{+json}', '{+cbor}'
and '{+cbor,+bin}' node options in sess_build_logline(). The series
is already known to cause a slight performance regression in
sess_build_logline(), mainly due to 0d1e99c08, 3a3bdf1c7, 2e4cc517b,
3f2e8d0ed. Tests are being carried out and optimizations should be
expected in a near future to match up with the original performance
for most common uses (ie: when no encoding is used). Note: unless
you're dealing with 100k+ requests per second, you have no chance to
ever detect the small perf regression, at best you may notice a few
percent increase in CPU usage. Since this is very small, we preferred
to expose the feature regardless so as to get more feedback on it.
- the stats-file feature was finally merged. It allows to dump and
preload stats counters across a reload. This has been mostly requested
by those who are using counters differences over a period to estimate
an activity. Not all counters are reloaded yet, but a number of
cumulative counters (requests, sessions, bytes, status codes) can be
transferred for frontends, backends, listeners, and servers. The
principle is that a complete dump of the current stats is produced
from the CLI using "dump stats-file" sent to a file (like with the
state file), and the new process when starting, opens that file,
figures which objects have counters available and presets their stats
counters from those in the file. Rates and ages are not reloaded yet.
Only objects having a guid assigned will be reloaded, since it is the
only criterion that is used to identify one such object (i.e. no more
ambiguity with server templates etc). We are thinking about providing
a way to automatically assign guids to objects to make this more
seamless for the many who manage their configs manually and would still
like to see their stats transferred, but we already anticipate that
different users coming from different use cases will have different
expectations on how to produce a stable guid, so for now we'll wait
for suggestions instead of trying to influence everyone with our first
thoughts ;-) Please look at "stats-file" in the doc for more info.
This feature was also an opportunity for performing a large cleanup
in the huge "stats.c" file and splitting it.
- the "uuid()" sample fetch function, which takes an optional version
in argument now also supports "7" for UUIDv7 (Thanks Tim!). These
UUIDs regroup many properties found in ULID and other mechanisms,
one of the most interesting one being time-based locality that, for
example, eases the archiving of old data, or the grouping of events
on systems where they'll be processed together.
- an interesting debugging feature that I was not aware of was
contributed by David Carlier: it allows to assign a name to some
memory areas on recent Linux versions (>=5.17) so that when reading
the process map (/proc/$pid/maps or using pmap), the area name
appears there. For now it's only applied to the shctx parts (SSL
and HTTP cache), but I'm already seeing how it could also be
generalized to rings, startup-logs, LRU cache, emergency buffers etc.
- as discussed a while ago, the "wait ... srv-unused" CLI command was
finally renamed to "wait ... srv-removable" to better match the
condition.
- and usual cleanups, regtests etc.
For what's remaining, I'm still trying to see if the fix we estimate for
the low-memory condition on buffers will work or if we should just change
the code everywhere to return hard errors when this happens. Hopefully by
the middle of next week I should know if it's worth going further. I'd
also like to re-apply the mt_list update so that we get the cleaner API
for the LTS version and ease backports or surrounding fixes. There are
some updates and cleanups almost ready around the linux capabilities to
permit to also support namespaces. Passing the gRPC RST reasons between
client and server should also be OK (it works in the lab, it's "just" a
matter to limit what's exposed not to get
