Re: [PATCH] Revert "CI: Build VTest with clang"
On Wed, May 12, 2021 at 09:08:49PM +0200, Tim Duesterhus wrote: > The issue with VTest not building properly in gcc is fixed since commit > vtest/VTest@0730540c43a2a23436b43f46327d6bac644d816d. Revert the patch to keep > the CI configuration simple. Pushed, thanks Tim! Willy
[PATCH] Revert "CI: Build VTest with clang"
The issue with VTest not building properly in gcc is fixed since commit
vtest/VTest@0730540c43a2a23436b43f46327d6bac644d816d. Revert the patch to keep
the CI configuration simple.
This reverts commit e61f53eb44a390f9a8c8c4f34077c365942e0729.
---
.github/workflows/vtest.yml | 2 +-
.travis.yml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/.github/workflows/vtest.yml b/.github/workflows/vtest.yml
index 1d62f98f3..cb52f27d6 100644
--- a/.github/workflows/vtest.yml
+++ b/.github/workflows/vtest.yml
@@ -63,7 +63,7 @@ jobs:
curl -fsSL https://github.com/vtest/VTest/archive/master.tar.gz -o
VTest.tar.gz
mkdir VTest
tar xvf VTest.tar.gz -C VTest --strip-components=1
-make -C VTest -j$(nproc) FLAGS="-O2 -s -Wall" CC=clang
+make -C VTest -j$(nproc) FLAGS="-O2 -s -Wall"
sudo install -m755 VTest/vtest /usr/local/bin/vtest
- name: Install SSL ${{ matrix.ssl }}
if: ${{ matrix.ssl && matrix.ssl != 'stock' }}
diff --git a/.travis.yml b/.travis.yml
index 37b667bc1..1aa415aa8 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -40,7 +40,7 @@ matrix:
install:
- git clone https://github.com/VTest/VTest.git ../vtest
# Special flags due to: https://github.com/vtest/VTest/issues/12
- - make -C ../vtest FLAGS="-O2 -s -Wall" CC=clang
+ - make -C ../vtest FLAGS="-O2 -s -Wall"
script:
- make -j$(nproc) ERR=1 TARGET=linux-glibc CC=$CC DEBUG=-DDEBUG_STRICT=1
$FLAGS
--
2.31.1
Re: [PR] Correct example reload command in the document
Hello, On Mon, May 10, 2021 at 05:23:02PM +0200, PR Bot wrote: > Description: >Current example is: > >`echo "reload" | socat /var/run/haproxy- >master.sock` > >it will cause socat error: > >`exactly 2 >addresses required (there are 1); use option "-h" for help` >Correct working command is: > >`echo "reload" | socat >/var/run/haproxy-master.sock stdin` Indeed! We can also use "socat /path/to/socket -" by the way. I've slightly adjusted the subject of the commit message and merged it. Thank you! Willy
Re: Inconsistent reading of txn vars from Lua script
On Wed, May 12, 2021 at 02:12:44PM -0300, Joao Morais wrote: > > It's not a matter of first or second access. It's that the function > > you used initially resulted in always allocating an entry for the > > variable's name, causing some huge memory usage for those who were > > using them like maps and performing random lookups there. In order > > to avoid this, Tim added an extra argument saying that we're just > > performing an opportunistic lookup and that the variable must not > > be created if it does not exist. > > Afaics this is only an option for set_var()? Here is the doc: > > TXN.set_var(TXN, var, value[, ifexist]) > TXN.get_var(TXN, var) > http://www.arpalert.org/src/haproxy-lua-api/2.3/index.html > (link is broken from haproxy site, is the source versioned > somewhere so I can send a patch?) > > So lookups would still create variables, hence the "in the second run it > works" - my second script (which reads) create the entry and my first script > (which writes with ifexists true) can find it and update in the second run > and beyond. That looks really odd, but you're probably right :-( I'll need to have a look at the code to check. Maybe get_var() also needs that argument, or maybe there is something to check if a variable exists, I don't know. But I don't like the way all of this works in general. I think the creation of a variable on a lookup only results from an internal API limitation that was quickly worked around when variables were exposed to Lua, and that it's not too late to fix it. Willy
Re: Inconsistent reading of txn vars from Lua script
> Em 12 de mai. de 2021, à(s) 02:47, Willy Tarreau escreveu: > > On Tue, May 11, 2021 at 05:41:28PM -0300, Joao Morais wrote: > >> Just to confirm how it works, I created the snippet below: >> >>http-request lua.auth ## assigning txn.core >>http-request return lf-string %[var(txn.code)] content-type text/plain >> >> It worked since the first run and this is the only place I declared txn.code. >> Does this mean that a var is created in the following conditions? >> Any change in the sentences below? >> >> - after the first read from a Lua script >> - after the first write from a Lua script provided that ifexists parameter >> is set to false >> - always exists, if used anywhere in the configuration file > > It's not a matter of first or second access. It's that the function > you used initially resulted in always allocating an entry for the > variable's name, causing some huge memory usage for those who were > using them like maps and performing random lookups there. In order > to avoid this, Tim added an extra argument saying that we're just > performing an opportunistic lookup and that the variable must not > be created if it does not exist. Afaics this is only an option for set_var()? Here is the doc: TXN.set_var(TXN, var, value[, ifexist]) TXN.get_var(TXN, var) http://www.arpalert.org/src/haproxy-lua-api/2.3/index.html (link is broken from haproxy site, is the source versioned somewhere so I can send a patch?) So lookups would still create variables, hence the “in the second run it works” - my second script (which reads) create the entry and my first script (which writes with ifexists true) can find it and update in the second run and beyond. > Other parts of the code (the native config parts I mean) which use > variables always result in a creation because these names are static. > So my understanding is that it can be simplified to this: > - a variable declared in the config always exists > - a variable accessed from Lua with ifexists set to true will not >be created but will be found if it exists > - a vraiable accessed from Lua with ifexists set to false or not >present will always be created during the lookup. Taking the sentence above I’d update this to: - s/variable accessed/variable updated, set_var(),/ - variable accessed from Lua, get_var(), will always be created Does this make any sense?
HME Professionals
Hi, I'm curious to know, If you would be interested in purchasing Home Medical Equipment Professionals. Titles: * HME Providers * Pharmacy and Drug Store Owners * Rehab Therapist/Providers * Respiratory Therapist/Providers * Home Health Agencies * Home Health Nurses * Hospitals * Insurance/Healthcare Payers * Occupational Therapists * Physical Therapists * Case Managers * Distributors If you're open to learning more, I'm happy to send over a Pricing, Counts & Sample data for your review. Looking forward to seeing if you agree it's a good fit for you guys. Thank you, Regards, Laura McMullen Sales executive Fortune contacts
Re: [PATCH] BUILD/MINOR: opentracing: fixed compilation with filter, enabled
On Wed, May 12, 2021 at 12:37:04PM +0500, ??? wrote: > I did not mean to postpone Miroslav's patch :) Ah got it, then it's not postponing it's just getting his patch in before 2.4 :-) Willy
Re: [PATCH] BUILD/MINOR: opentracing: fixed compilation with filter, enabled
Hi Miroslav, On Tue, May 11, 2021 at 07:34:05PM +0200, Miroslav Zagorac wrote: > Hello, > > The inclusion of header files proxy.h and tools.h was added to the > addons/ot/include/include.h file. Without this HAProxy cannot be > compiled if the OpenTracing filter is to be used. Thank you, now merged! Willy
Re: Inconsistent reading of txn vars from Lua script
On Wed, May 12, 2021 at 09:12:25AM +0200, Tim Düsterhus wrote: > Willy, > > On 5/12/21 7:47 AM, Willy Tarreau wrote: > > Interestingly, the code for variables was initially made for the config, > > so it doesn't seem to destroy variable names when they're released since > > that was pointless with the config. I think that code should be revisited > > in 2.5 to improve the situation (e.g. by marking that the variable was > > dynamically allocated maybe), but I don't know this part well so I'll > > probably stop before starting to suggest stupidities :-) > > > > There's also this related issue from back when I implemented this additional > parameter: > > https://github.com/haproxy/haproxy/issues/624 Yes, and it's still unclear to me how this storage is currently arranged, (i.e. why only store names?) I should have a look for 2.5 probably. Willy
Re: [PATCH] BUILD/MINOR: opentracing: fixed compilation with filter, enabled
I did not mean to postpone Miroslav's patch :) On Wed, May 12, 2021, 10:39 AM Willy Tarreau wrote: > Hi Ilya, > > On Tue, May 11, 2021 at 10:59:46PM +0500, ??? wrote: > > I tried opentracing ci, I estimate 1-2 weeks to stabilize. Can we delay > 2.4 > > after that? > > If you mean delaying 2.4 after some extra CI is ready, not at all. What > would delay it is a big last minute regression, but postponing a release > just to wait for something never works as stuff continues to accumulate. > Believe me, that's what turned the planed 6-months cycle of 1.5 into 4.5 > years. In addition, the feedback from users just after a release is always > faster and more valuable than anything we can try to imagine at the last > minute. > > Do not worry, we do have time to continue to improve the CI (which is > already great), there's no emergency and whatever you provide can be > merged at any moment since it focuses on the development tree, so do > not feel pressured by an upcoming version nor any timing in general. > > Cheers, > Willy >
Re: Inconsistent reading of txn vars from Lua script
Willy, On 5/12/21 7:47 AM, Willy Tarreau wrote: Interestingly, the code for variables was initially made for the config, so it doesn't seem to destroy variable names when they're released since that was pointless with the config. I think that code should be revisited in 2.5 to improve the situation (e.g. by marking that the variable was dynamically allocated maybe), but I don't know this part well so I'll probably stop before starting to suggest stupidities :-) There's also this related issue from back when I implemented this additional parameter: https://github.com/haproxy/haproxy/issues/624 Best regards Tim Düsterhus
