stable-bot: Bugfixes waiting for a release 2.1 (27), 2.0 (24)

2020-05-19 Thread stable-bot
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

Distance Learning Package: Bid Writing

2020-05-19 Thread NFP Workshops
NFP WORKSHOPS 18 Blake Street, York YO1 8QG Affordable Training Courses for Charities, Schools & Public Sector Organisations This email has been sent to haproxy@formilux.org CLICK TO UNSUBSCRIBE FROM LIST Alternatively send a blank e-mail to unsubscr...@nfpmail1902.co.uk quoting

Re: raise() on HAProxy 2.0

2020-05-19 Thread Olivier D
Hello Willy, Le ven. 15 mai 2020 à 17:33, Willy Tarreau a écrit : > > Is it 100% reproducible and if so can you please share a minimal config > and reproducer so that we can quickly focus on it ? > Unfortunately I was unable to reproduce it. It only happens for several hours in a row, then stop

Re: [PATCH 0/6] Lua variable handling

2020-05-19 Thread Christopher Faulet
Le 19/05/2020 à 16:06, Tim Düsterhus a écrit : Now back on topic. Instead of adding more parameters to set_var(), I'd prefer a warning instead. If someone is using set_var() from Lua, and that variable is never used or set in the rest of the config, we would know that. Additionally, one can

Re: 2.0.14 + htx / retry-on all-retryable-errors -> sometimes wrong backend/server used

2020-05-19 Thread Jarno Huuskonen
Hi, On Tue, 2020-05-19 at 15:58 +0200, Christopher Faulet wrote: > It was already reported on github and seems to be fixed. We are just > waiting a > feedback to be sure it is fixed before backporting the patch. See > https://github.com/haproxy/haproxy/issues/623. > > If you try the latest 2.2

Re: [PATCH 0/6] Lua variable handling

2020-05-19 Thread Christopher Faulet
Le 19/05/2020 à 13:49, Tim Duesterhus a écrit : Christopher, Thierry, this patch series implements the solution discussed in GitHub issue #624: https://github.com/haproxy/haproxy/issues/624#issuecomment-630590470 I felt pretty dirty having to copy and paste my changes to all three versions of

Re: [PATCH 0/6] Lua variable handling

2020-05-19 Thread Tim Düsterhus
Adis, Am 19.05.20 um 15:57 schrieb Adis Nezirovic: > However, nothing in the code checks that variable name is formed > correctly (with correct prefix, such as "txn."), or that the rest of the > variable name is correct. > > Lua code using set_var() with wrong name silently fails, the variable

Re: 2.0.14 + htx / retry-on all-retryable-errors -> sometimes wrong backend/server used

2020-05-19 Thread Christopher Faulet
Le 19/05/2020 à 15:36, Jarno Huuskonen a écrit : Hi, I think I found a case when haproxy-2.0.14 with htx and retry-on all-retryable-errors sometimes seems to select wrong backend/server to retry. (Doesn't happen on every retry). I found that sometimes when our wordpress backend gave 500 error

Re: [PATCH 0/6] Lua variable handling

2020-05-19 Thread Adis Nezirovic
Tim, First, not a a direct comment on your patches, but before I forget, I'd like to point out that there is one more thing which need fixing in regard to Lua variables: TXN.set_var(TXN, var, value) where "var" is noted as: The var name according with the HAProxy syntax

Re: 2.0.14 + htx / retry-on all-retryable-errors -> sometimes wrong backend/server used

2020-05-19 Thread Tim Düsterhus
Jarno, Am 19.05.20 um 15:36 schrieb Jarno Huuskonen: > I think I found a case when haproxy-2.0.14 with htx and retry-on > all-retryable-errors sometimes seems to select wrong backend/server > to retry. (Doesn't happen on every retry). > I believe this is a duplicate of this issue:

2.0.14 + htx / retry-on all-retryable-errors -> sometimes wrong backend/server used

2020-05-19 Thread Jarno Huuskonen
Hi, I think I found a case when haproxy-2.0.14 with htx and retry-on all-retryable-errors sometimes seems to select wrong backend/server to retry. (Doesn't happen on every retry). I found that sometimes when our wordpress backend gave 500 error haproxy would retry on wrong backend. Here's a

[PATCH 2/6] MINOR: lua: Use vars_unset_by_name_ifexist()

2020-05-19 Thread Tim Duesterhus
There is no good reason to register a variable name, just to unset that value that could not even be set without the variable existing. This change should be safe, may be backported if desired. --- src/hlua.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/hlua.c

[PATCH 5/6] MINOR: lua: Make `set_var()` and `unset_var()` return success

2020-05-19 Thread Tim Duesterhus
This patch makes `set_var()` and `unset_var()` return a boolean indicating success. --- reg-tests/lua/set_var.lua | 12 reg-tests/lua/set_var.vtc | 29 + src/hlua.c| 24 3 files changed, 53 insertions(+), 12

[PATCH 4/6] MINOR: vars: Make vars_(un|)set_by_name(_ifexist|) return a success value

2020-05-19 Thread Tim Duesterhus
Change the return type from `void` to `int` and return whether setting the variable was successful. --- include/proto/vars.h | 6 +++--- src/vars.c | 25 + 2 files changed, 16 insertions(+), 15 deletions(-) diff --git a/include/proto/vars.h

[PATCH 0/6] Lua variable handling

2020-05-19 Thread Tim Duesterhus
Christopher, Thierry, this patch series implements the solution discussed in GitHub issue #624: https://github.com/haproxy/haproxy/issues/624#issuecomment-630590470 I felt pretty dirty having to copy and paste my changes to all three versions of `set_var` and `unset_var`. This should be

[PATCH 1/6] REGTESTS: Add missing OPENSSL to REQUIRE_OPTIONS for lua/txn_get_priv

2020-05-19 Thread Tim Duesterhus
The test uses the `ssl` keyword, add `OPENSSL` as a requirement. Should be backported to all branches with that test. --- reg-tests/lua/txn_get_priv.vtc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/reg-tests/lua/txn_get_priv.vtc b/reg-tests/lua/txn_get_priv.vtc index

[PATCH 3/6] CLEANUP: vars: Remove void vars_unset_by_name(const char*, size_t, struct sample*)

2020-05-19 Thread Tim Duesterhus
With "MINOR: lua: Use vars_unset_by_name_ifexist()" the last user was removed and as outlined in that commit there is no good reason for this function to exist. May be backported together with the commit mentioned above. --- include/proto/vars.h | 1 - src/vars.c | 15 ---

[PATCH 6/6] MEDIUM: lua: Add `ifexist` parameter to `set_var`

2020-05-19 Thread Tim Duesterhus
As discussed in GitHub issue #624 Lua scripts should not use variables that are never going to be read, because the memory for variable names is never going to be freed. Add an optional `ifexist` parameter to the `set_var` function that allows a Lua developer to set variables that are going to be