Page MenuHomePhabricator

Beta cluster haproxy does not support `warn-blocked-traffic-after` keyword
Open, HighPublic

Description

When processing an unblock request, I noticed haproxy in beta has invalid config:

root@deployment-cache-upload08:~# haproxy -c -f /etc/haproxy/haproxy.cfg 
[NOTICE]   (1149872) : haproxy version is 2.8.18-1~bpo11+1
[NOTICE]   (1149872) : path to executable is /usr/sbin/haproxy
[ALERT]    (1149872) : config : parsing [/etc/haproxy/haproxy.cfg:11] : unknown keyword 'warn-blocked-traffic-after' in 'global' section
[ALERT]    (1149872) : config : Error(s) found in configuration file : /etc/haproxy/haproxy.cfg
[ALERT]    (1149872) : config : Fatal errors found in configuration.
root@deployment-cache-upload08:~#

This is happening since https://gerrit.wikimedia.org/r/c/operations/puppet/+/1295007, where @CDanis added warn-blocked-traffic-after 500ms. This parameter doesn't seem to be present in haproxy 2.8 on beta.

Event Timeline

Pushed this on beta as a stopgap:

root@deployment-puppetserver-1:/srv/git/operations/puppet# git diff HEAD~ HEAD
diff --git a/modules/profile/templates/cache/haproxy.cfg.erb b/modules/profile/templates/cache/haproxy.cfg.erb
index 37f6508a94..c7b394a111 100644
--- a/modules/profile/templates/cache/haproxy.cfg.erb
+++ b/modules/profile/templates/cache/haproxy.cfg.erb
@@ -17,7 +17,8 @@ global
     hard-stop-after 1m
     set-dumpable
     nbthread <%= num_threads %>
-    warn-blocked-traffic-after 500ms
+    # commented out, as it is not recognised in beta (T428052)
+    # warn-blocked-traffic-after 500ms
 <%
     htsets = @facts['numa']['device_to_htset'][@numa_iface]
     cpus = htsets.flatten.join(' ')
root@deployment-puppetserver-1:/srv/git/operations/puppet#
bd808 renamed this task from haproxy in Beta cluster has invalid config to Beta cluster haproxy does not support `warn-blocked-traffic-after` keyword.Wed, Jun 3, 3:58 PM
bd808 triaged this task as High priority.
bd808 updated the task description. (Show Details)
bd808 subscribed.

Pushed this on beta as a stopgap:

Thanks for the workaround @Urbanecm_WMF.

When possible we like to track the stack of Beta hacksworkarounds in Gerrit using hashtag:beta-cherry-picked. For [BETA HACK] patches specifically we have been using the WIP status to indicate in Gerrit that the patch is not a thing we expect to be merged. Hopefully this one won't live long enough to make it worthwhile to setup all that tracking, but because you are the sort of awesome person who is likely to help in this area again in the future I thought it would be worth pointing out the best practices.

The Beta Cluster cache nodes are Debian Bullseye running HAProxy version 2.8.18-1~bpo11+1 2025/12/26. It looks like the prod CDN edge is using Debian Trixie and HAProxy 3.2.15-1~bpo13+1.

See also: T401839: Migrate deployment-prep away from Debian Bullseye to Bookworm/Trixie

The Beta Cluster cache nodes are Debian Bullseye running HAProxy version 2.8.18-1~bpo11+1 2025/12/26. It looks like the prod CDN edge is using Debian Trixie and HAProxy 3.2.15-1~bpo13+1.

See also: T401839: Migrate deployment-prep away from Debian Bullseye to Bookworm/Trixie

Yes that is correct, for the CDN side. In this particular case, we can put it under one of our usual guards.