stable-bot: Bugfixes waiting for a release 2.1 (19), 2.0 (15)
Hi, This is a friendly bot that watches fixes pending for the next haproxy-stable release! One such e-mail is sent periodically once patches are waiting in the last maintenance branch, and an ideal release date is computed based on the severity of these fixes and their merge date. Responses to this mail must be sent to the mailing list. Last release 2.1.11 was issued on 2021-01-08. There are currently 19 patches in the queue cut down this way: - 7 MEDIUM, first one merged on 2021-01-26 - 12 MINOR, first one merged on 2021-01-26 Thus the computed ideal release date for 2.1.12 would be 2021-03-23, which is in five weeks or less. Last release 2.0.20 was issued on 2021-01-08. There are currently 15 patches in the queue cut down this way: - 7 MEDIUM, first one merged on 2021-01-28 - 8 MINOR, first one merged on 2021-01-28 Thus the computed ideal release date for 2.0.21 would be 2021-03-25, which is in five weeks or less. The current list of patches in the queue is: - 2.0, 2.1 - MEDIUM : ssl: check a connection's status before computing a handshake - 2.0, 2.1 - MEDIUM : mux-h2: fix read0 handling on partial frames - 2.0 - MEDIUM : mux-h2: Be sure to enter in demux loop even if dbuf is empty - 2.0, 2.1 - MEDIUM : mux-h2: handle remaining read0 cases - 2.1 - MEDIUM : ssl/cli: abort ssl cert is freeing the old store - 2.0, 2.1 - MEDIUM : mux-h2: do not quit the demux loop before setting END_REACHED - 2.0, 2.1 - MEDIUM : filters/htx: Fix data forwarding when payload length is unknown - 2.0, 2.1 - MEDIUM : stats: add missing INF_BUILD_INFO definition - 2.0, 2.1 - MINOR : init: Use a dynamic buffer to set HAPROXY_CFGFILES env variable - 2.0, 2.1 - MINOR : peers: Wrong "new_conn" value for "show peers" CLI command. - 2.0, 2.1 - MINOR : stick-table: Always call smp_fetch_src() with a valid arg list - 2.1 - MINOR : mux_h2: missing space between "st" and ".flg" in the "show fd" helper - 2.0, 2.1 - MINOR : xxhash: make sure armv6 uses memcpy() - 2.0, 2.1 - MINOR : mworker: define _GNU_SOURCE for strsignal() - 2.1 - MINOR : init: enforce strict-limits when using master-worker - 2.1 - MINOR : threads: Fixes the number of possible cpus report for Mac. - 2.0, 2.1 - MINOR : sample: check alloc_trash_chunk return value in concat() - 2.1 - MINOR : ssl: init tmp chunk correctly in ssl_sock_load_sctl_from_file() - 2.0, 2.1 - MINOR : config: fix leak on proxy.conn_src.bind_hdr_name - 2.0, 2.1 - MINOR : sample: Memory leak of sample_expr structure in case of error -- The haproxy stable-bot is freely provided by HAProxy Technologies to help improve the quality of each HAProxy release. If you have any issue with these emails or if you want to suggest some improvements, please post them on the list so that the solutions suiting the most users can be found.
Re: Discussion around a first set of config preprocessing functions
Willy, Am 16.02.21 um 11:28 schrieb Willy Tarreau: >- defined(name) : true if this environment variable is set This one is fine for me. But I believe would be redundant with `streq($name,"")`. >- keyword(name) : true if this config keyword is registered >- service(name) : true if this service is registered >- action(name) : true if this action is registered >- option(name) : true if this proxy option exists I don't think these are a good idea. They are overly specific and pretty much redundant with a version comparison. I would assume that one only shoots their foot with those (e.g. with typos and inconsistent behavior). You should know what you are running in production and then you can switch based on versions. Generally: Either a specific configuration line is important or it is not (then it should be commented or deleted). >- configured(name): true if this feature was configured at build time >- supported(name): true if this feature is supported at run time I'm not sure about these. They sit between a version comparison (which I think is good) and the super granular feature detection (which I think is not good). There should be less risk in enabling a feature flag vs. upgrading to a new HAProxy version. Thus I expect a more homogeneous LB fleet with regard to feature flags, making these less important to have. It's hard to me to think of a situation where it would make sense to e.g. run Lua only on half of the LBs. >- version_atleast(): true if the haproxy version is at least this one >- version_before(): the opposite of the above: I think this is a must have and it's the one I planned to implement. In fact I wished to have this in the past. It would allow for a seamless upgrades of HAProxy where half of the cluster runs some older and the other half runs some newer version. In my specific case I would have used it when `http-error` was newly introduced to already add the unique ID to the error pages on the HAProxy 2.2 machines, while leaving it out for the older ones. Similarly it would have allowed me to already remove the Lua script I was running in favor of `http-request return`. >- streq(a,b): compare two strings (should be careful, maybe it would > be better to rethink about this for expressions later): I think this one is useful for the examples you gave. Best regards Tim Düsterhus
[PATCH]: BUILD/MEDIUM da pcre2 support
Hi, Here a patch proposal to update the DeviceAtlas Detection build in order to support the pcre2 library as option. Would be nice if backported back to the supported stable releases. Thanks in advance. Kind regards. From c90231b41e7adc2de199d6c014282d00f24e78a8 Mon Sep 17 00:00:00 2001 From: David Carlier Date: Tue, 16 Feb 2021 11:37:45 + Subject: [PATCH] BUILD/MEDIUM: da Adding pcre2 support. The DeviceAtlas Detection API now supports also the pcre2 library, and some users wish to have exclusively this version in their environment. Also, there is no longer new development happening in the legacy pcre(1) counterpart. Simple check in the build process as the mutual exclusivity check between the two are already taking care of early on. Moving the check to the part only when we build haproxy + the API from source as the other case the API is already built with the chosen regex library separately. --- Makefile | 11 --- doc/DeviceAtlas-device-detection.txt | 6 +++--- 2 files changed, 11 insertions(+), 6 deletions(-) diff --git a/Makefile b/Makefile index 613067f75..72fc0322d 100644 --- a/Makefile +++ b/Makefile @@ -615,9 +615,6 @@ OPTIONS_OBJS+= src/hlua.o src/hlua_fcn.o endif ifneq ($(USE_DEVICEATLAS),) -ifeq ($(USE_PCRE),) -$(error the DeviceAtlas module needs the PCRE library in order to compile) -endif # Use DEVICEATLAS_SRC and possibly DEVICEATLAS_INC and DEVICEATLAS_LIB to force path # to DeviceAtlas headers and libraries if needed. DEVICEATLAS_SRC = @@ -626,6 +623,14 @@ DEVICEATLAS_LIB = $(DEVICEATLAS_SRC) ifeq ($(DEVICEATLAS_SRC),) OPTIONS_LDFLAGS += -lda else +ifeq ($(USE_PCRE),) +ifeq ($(USE_PCRE2),) +$(error the DeviceAtlas module needs the PCRE or the PCRE2 library in order to compile) +endif +endif +ifneq ($(USE_PCRE2),) +OPTIONS_CFLAGS += -DDA_REGEX_HDR=\"dac_pcre2.c\" -DDA_REGEX_TAG=2 +endif OPTIONS_OBJS += $(DEVICEATLAS_LIB)/json.o OPTIONS_OBJS += $(DEVICEATLAS_LIB)/dac.o endif diff --git a/doc/DeviceAtlas-device-detection.txt b/doc/DeviceAtlas-device-detection.txt index 2358c5cc6..ccafaa0b1 100644 --- a/doc/DeviceAtlas-device-detection.txt +++ b/doc/DeviceAtlas-device-detection.txt @@ -2,10 +2,10 @@ DeviceAtlas Device Detection In order to add DeviceAtlas Device Detection support, you would need to download -the API source code from https://deviceatlas.com/deviceatlas-haproxy-module and -once extracted : +the API source code from https://deviceatlas.com/deviceatlas-haproxy-module. +The build supports the USE_PCRE and USE_PCRE2 options. Once extracted : -$ make TARGET= USE_PCRE=1 USE_DEVICEATLAS=1 DEVICEATLAS_SRC= +$ make TARGET= USE_PCRE (or USE_PCRE2=1) USE_DEVICEATLAS=1 DEVICEATLAS_SRC= Optionally DEVICEATLAS_INC and DEVICEATLAS_LIB may be set to override the path to the include files and libraries respectively if they're not in the source -- 2.30.0
Re: Discussion around a first set of config preprocessing functions
Hello,
I'm happy using dpapi to query/change values. Actually any external
template engine is ok.
not sure that having that level of complication inside worth efforts spent
on it.
as a side question, would it be as easy as it is now to use dpapi on top of
"if/else" config ?
вт, 16 февр. 2021 г. в 15:31, Willy Tarreau :
> Hi all,
>
> Tim and I started to discuss a few functions worth supporting in the
> config for use with the new ".if" preprocessing macro. We need to think
> them well enough so that we don't need to change their meaning over time
> and that they allow more portable configs across versions.
>
> I'm sure we'll be limited to something simple for 2.4 (we will probably
> not support expressions, just simple boolean functions). Among the things
> I started to think about, I had the following in mind:
>
>- defined(name) : true if this environment variable is set
>
> .if defined(HAP_NBTHREAD)
> nbthread HAP_NBTHREAD
> .elif defined(HAP_NBPROC)
> nbproc HAP_NBPROC
> .endif
>
>- keyword(name) : true if this config keyword is registered
>
> .if keyword(chroot)
> chroot /path/to
> .endif
>
>- service(name) : true if this service is registered
>
>
> .if service(prometheus-exporter)
> use-service prometheus-exporter if { path_beg /promex }
> .endif
>
>- action(name) : true if this action is registered
>
> .if action(silent-drop)
> tcp-request silent-drop if { src -f banned.acl }
> .endif
>
>- option(name) : true if this proxy option exists
>
> .if option(http-use-htx)
> option http-use-htx
> .endif
>
>- configured(name): true if this feature was configured at build time
>
> .if configured(LUA)
> lua-load hello.lua
> .endif
>
>- supported(name): true if this feature is supported at run time
>
> .if supported(SPLICE)
> tune.bufsize 16384
> .else
> tune.bufsize 65536
> .endif
>
>- version_atleast(): true if the haproxy version is at least this one
>
> .if version_atleast(2.4)
> tune.sched.low-latency on
> .endif
>
>- version_before(): the opposite of the above:
>
> .if version_before(2.0)
> option http-use-htx
> .endif
>
>- streq(a,b): compare two strings (should be careful, maybe it would
> be better to rethink about this for expressions later):
>
> .if streq(HAP_ENVIRONMENT,prod)
> chroot /path/to
> .else
> set-dumpable
> .endif
>
> or even for other tests:
>
> .if streq(HOSTNAME,node1)
> peer node1 1.1.1.1 local
> peer node2 1.1.1.2
> .else
> peer node1 1.1.1.1
> peer node2 1.1.1.2 local
> .endif
>
> I'm still not completely sold to these, because I'm suspecting that we
> need to differentiate what's supported in global/listen/bind/server
> parts for the "keyword" part. Maybe even other ones. I also thought
> that being able to check for some components' types and versions could
> be helpful (e.g. enable/disable certain features between openssl and
> boringssl).
>
> I also thought it could be useful to have a few special environment
> variable
> names like ${LINE} and ${FILE} to indicate where we're parsing. This could
> serve in .warning/.error as well as in logs sometimes.
>
> I'm purposely dumping this here as-is because I don't want to think too
> much about it without consulting those supposed to use them :-)
>
> So all ideas and criticisms welcome.
>
> Willy
>
>
Discussion around a first set of config preprocessing functions
Hi all,
Tim and I started to discuss a few functions worth supporting in the
config for use with the new ".if" preprocessing macro. We need to think
them well enough so that we don't need to change their meaning over time
and that they allow more portable configs across versions.
I'm sure we'll be limited to something simple for 2.4 (we will probably
not support expressions, just simple boolean functions). Among the things
I started to think about, I had the following in mind:
- defined(name) : true if this environment variable is set
.if defined(HAP_NBTHREAD)
nbthread HAP_NBTHREAD
.elif defined(HAP_NBPROC)
nbproc HAP_NBPROC
.endif
- keyword(name) : true if this config keyword is registered
.if keyword(chroot)
chroot /path/to
.endif
- service(name) : true if this service is registered
.if service(prometheus-exporter)
use-service prometheus-exporter if { path_beg /promex }
.endif
- action(name) : true if this action is registered
.if action(silent-drop)
tcp-request silent-drop if { src -f banned.acl }
.endif
- option(name) : true if this proxy option exists
.if option(http-use-htx)
option http-use-htx
.endif
- configured(name): true if this feature was configured at build time
.if configured(LUA)
lua-load hello.lua
.endif
- supported(name): true if this feature is supported at run time
.if supported(SPLICE)
tune.bufsize 16384
.else
tune.bufsize 65536
.endif
- version_atleast(): true if the haproxy version is at least this one
.if version_atleast(2.4)
tune.sched.low-latency on
.endif
- version_before(): the opposite of the above:
.if version_before(2.0)
option http-use-htx
.endif
- streq(a,b): compare two strings (should be careful, maybe it would
be better to rethink about this for expressions later):
.if streq(HAP_ENVIRONMENT,prod)
chroot /path/to
.else
set-dumpable
.endif
or even for other tests:
.if streq(HOSTNAME,node1)
peer node1 1.1.1.1 local
peer node2 1.1.1.2
.else
peer node1 1.1.1.1
peer node2 1.1.1.2 local
.endif
I'm still not completely sold to these, because I'm suspecting that we
need to differentiate what's supported in global/listen/bind/server
parts for the "keyword" part. Maybe even other ones. I also thought
that being able to check for some components' types and versions could
be helpful (e.g. enable/disable certain features between openssl and
boringssl).
I also thought it could be useful to have a few special environment variable
names like ${LINE} and ${FILE} to indicate where we're parsing. This could
serve in .warning/.error as well as in logs sometimes.
I'm purposely dumping this here as-is because I don't want to think too
much about it without consulting those supposed to use them :-)
So all ideas and criticisms welcome.
Willy
