from:"Frederic Lecaille"


On 6/24/19 10:03 AM, Tim Düsterhus wrote:

Willy,

Am 24.06.19 um 07:33 schrieb Willy Tarreau:

Hi Tim,


[snipped]


If it emits an error when using sizeof(int) instead of sizeof(*foo) where
foo is an pointer to unsigned int, it is bogus. I challenge you to present
me a relevant architecture where unsigned changes the allocated size!r


For C11 it is guaranteed that there is none according to this:
https://stackoverflow.com/a/13169473/782822


This is guaranteed since the beginning of C. Not only for C11. :)

Fred.

Re: [PATCH 4/9] BUG/MINOR: mworker: Fix segmentation fault during cfgparse


Hi Ilya,

On 6/24/19 8:25 AM, Илья Шипицин wrote:

I had to be mroe detailed :)

I meant "simple reg test" + address sanitizer which we run in travis

address sanitizer is capable of catching those things



No, we do not write reg test anymore for bugs which have very few chance 
to come back.


Fred.

Re: [PATCH 2/9] BUG/MINOR: log: Detect missing sampling ranges in config


On 6/24/19 11:01 AM, Frederic Lecaille wrote:

Hi Tim,

On 6/23/19 10:10 PM, Tim Duesterhus wrote:

Consider a config like:

 global
 log 127.0.0.1:10001 sample :10 local0

No sampling ranges are given here, leading to NULL being passed
as the first argument to qsort.

This configuration does not make sense anyway, a log without ranges
would never log. Thus output an error if no ranges are given.


Calling qsort() with such a  value is not a bug as far as the 
second argument (the size of the array with  as address) is 0.


See 7.20.5 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf


Well after having read this paragraph carefully:

"Pointer arguments on such a call shall still have valid values, as 
described in 7.1.4."


So, my understanding of this paragraph is that even if the size of the 
array is 0, the pointer to the array must be valid. If not, it is UB.



Fred.

Re: [PATCH 2/9] BUG/MINOR: log: Detect missing sampling ranges in config


Hi Tim,

On 6/23/19 10:10 PM, Tim Duesterhus wrote:

Consider a config like:

 global
log 127.0.0.1:10001 sample :10 local0

No sampling ranges are given here, leading to NULL being passed
as the first argument to qsort.

This configuration does not make sense anyway, a log without ranges
would never log. Thus output an error if no ranges are given.


Calling qsort() with such a  value is not a bug as far as the 
second argument (the size of the array with  as address) is 0.


See 7.20.5 http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf


This bug was introduced in d95ea2897eb951c72fd169f36b6a79905f2ed999.
This fix must be backported to HAProxy 2.0.
---
  src/log.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/src/log.c b/src/log.c
index ecbc7ab55..ef999d13f 100644
--- a/src/log.c
+++ b/src/log.c
@@ -929,6 +929,11 @@ int parse_logsrv(char **args, struct list *logsrvs, int 
do_del, char **err)
smp_rgs_sz++;
}
  
+		if (smp_rgs == NULL) {

+   memprintf(err, "no sampling ranges given");
+   goto error;
+   }
+
beg = smp_sz_str;
end = beg + strlen(beg);
new_smp_sz = read_uint((const char **), end);



I think this patch is correct but does not fix a bug. It helps the user 
in debugging its wrong configuration file.



Fred.

Re: missing table name src_conn_rate

2019-06-21 Thread Frederic Lecaille


On 6/20/19 1:02 PM, William Dauchy wrote:

Hi Fred,

On Thu, Jun 20, 2019 at 09:44:51AM +0200, Frederic Lecaille wrote:

In fact it seems I have broken something and missed this case.
Here is a patch which should fix this issue.


Thanks for the patch, it fixes the issue.


 From 1575a4bcdb52bbb8604521b6673557c178431deb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Thu, 20 Jun 2019 09:31:04 +0200
Subject: [PATCH] BUG/MAJOR: sample: Wrong stick-table name parsing in
  "if/unless" ACL condition.

This bug was introduced by 1b8e68e commit which supposed the stick-table was 
always
stored in struct arg at parsing time. This is never the case with the usage of
"if/unless" conditions in stick-table declared as backends. In this case, this 
is
the name of the proxy which must be considered as the stick-table name.


Tested-by: William Dauchy 


Thank you for this feedback William.

Willy, could you merge this patch please?

Fred.

Re: missing table name src_conn_rate

2019-06-20 Thread Frederic Lecaille


On 6/20/19 12:59 AM, William Dauchy wrote:

Hello,


Hello William,


We are using "rate limiting" config such as the one mentioned below:

backend foo
 stick-table type ip size 200k expire 30s store conn_rate(60s)
 tcp-request content track-sc1 src
 http-request deny deny_status 429 if { src_conn_rate ge 42000 }

While giving a try to v2.0 we are getting "missing table name in arg 1 of
ACL keyword 'src_conn_rate' in"
Did I missed something in the breaking changes of 2.0?


No.

In fact it seems I have broken something and missed this case.
Here is a patch which should fix this issue.

Fred.
>From 1575a4bcdb52bbb8604521b6673557c178431deb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Thu, 20 Jun 2019 09:31:04 +0200
Subject: [PATCH] BUG/MAJOR: sample: Wrong stick-table name parsing in
 "if/unless" ACL condition.

This bug was introduced by 1b8e68e commit which supposed the stick-table was always
stored in struct arg at parsing time. This is never the case with the usage of
"if/unless" conditions in stick-table declared as backends. In this case, this is
the name of the proxy which must be considered as the stick-table name.
---
 src/sample.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/src/sample.c b/src/sample.c
index 96102504b..94c605f92 100644
--- a/src/sample.c
+++ b/src/sample.c
@@ -1245,15 +1245,11 @@ int smp_resolve_args(struct proxy *p)
 			break;
 
 		case ARGT_TAB:
-			if (!arg->data.str.data) {
-ha_alert("parsing [%s:%d] : missing table name in arg %d of %s%s%s%s '%s' %s proxy '%s'.\n",
-	 cur->file, cur->line,
-	 cur->arg_pos + 1, conv_pre, conv_ctx, conv_pos, ctx, cur->kw, where, p->id);
-cfgerr++;
-continue;
-			}
+			if (arg->data.str.data)
+stktname = arg->data.str.area;
+			else
+stktname = px->id;
 
-			stktname = arg->data.str.area;
 			t = stktable_find_by_name(stktname);
 			if (!t) {
 ha_alert("parsing [%s:%d] : unable to find table '%s' referenced in arg %d of %s%s%s%s '%s' %s proxy '%s'.\n",
-- 
2.11.0

Re: VTest output change

2019-06-18 Thread Frederic Lecaille


On 6/17/19 3:19 PM, Poul-Henning Kamp wrote:

Hi,


Hi Poul-Henning,


For reason now obscured by history, VTest has a (relative) timestamp
on every line of its output:

***  v1   27.4 CLI RX  300
 v1   27.4 CLI RX|Cannot set the active VCL cold.
**   v1   27.4 CLI 300 
**   top  27.4 === varnish v1 -cliok "vcl.state vcl1 auto"
 v1   27.4 CLI TX|vcl.state vcl1 auto
***  v1   27.5 CLI RX  200
**   v1   27.5 CLI 200 

That makes it patently hard to rund diff(1) on VTest outputs.

I want to change this to instead emit separate timestamp lines
whenever the time has changed since the last output to the log:

 dT   3.864
***  v3   CLI RX  200
 v3   CLI RX|Child in state running
 v3   CLI TX|debug.listen_address
 dT   3.970
***  v3   CLI RX  200
 v3   CLI RX|/tmp/vtc.49670.11c55d2e/v3.sock -
 v3   CLI TX|debug.xid 999
 dT   4.076
 v3   vsl|  0 CLI - Rd debug.listen_address

Even with the increased precision to milliseconds, the output from
running all the Varnish Cache tests in verbose mode is still 7% smaller
than before.

The Varnish Cache project has OK'ed this, any objections from HAproxy ?


It seems there is no objection ;)

Thank you.


Fred.

Re: [BUG] memory leak with treads and stick-table/peers

2019-06-05 Thread Frederic Lecaille


On 6/5/19 3:06 PM, Emmanuel Hocdet wrote:


Hi,


Hi Emmanuel,

After switched to haproxy 1.9 with threads activated, i noticed a 
significant memory leak.


Is valgrind able to expose this memory leak?


With threads disable (and bind process omitted) leak disappear.

This seems to be related to stick-table/peers with regard to the 
(simplified) configuration.


Has this been revealed by a git bisect?

I am trying to understand the impact of the peers configuration 
simplification on your configuration because as far as I see you do not 
use this feature.


This feature is used only if you have "table" lines in "peers" sections.

Furthermore this feature has not been backported to 1.9. This is a 2.0 
specific feature. Or perhaps I have missed something.


This feature comes with at least this commit:

MEDIUM: stick-table: Stop handling stick-tables as proxies.


Fred.

Re: reg-tests are broken when running osx + openssl

2019-05-06 Thread Frederic Lecaille


On 5/6/19 11:25 AM, Frederic Lecaille wrote:

On 5/6/19 9:54 AM, Илья Шипицин wrote:

there's some random failure

https://travis-ci.com/haproxy/haproxy/jobs/197824840

looks like test is not stable


According to the log, S13 and S37 syslog servers have the same port: 42464


Obviously this is a vtest bug. I could sometimes reproduce it. I cannot 
reproduce anymore with this commit: : 
https://github.com/haproxyFred/VTest/commit/17871365a14d81234426ac203da3af30bb46e506


I have sent a PR for vtest for this issue: 
https://github.com/vtest/VTest/pull/13.


Fred.

Re: reg-tests are broken when running osx + openssl

2019-05-06 Thread Frederic Lecaille


On 5/6/19 9:54 AM, Илья Шипицин wrote:

there's some random failure

https://travis-ci.com/haproxy/haproxy/jobs/197824840

looks like test is not stable


According to the log, S13 and S37 syslog servers have the same port: 42464


Fred.

Re: reg-tests are broken when running osx + openssl

2019-05-05 Thread Frederic Lecaille


On 5/5/19 9:51 AM, Willy Tarreau wrote:

On Fri, May 03, 2019 at 07:27:48PM +0200, Frederic Lecaille wrote:

-  - env VTEST_PROGRAM=../vtest/vtest make reg-tests
+  - env TMPDIR=~/tmp VTEST_PROGRAM=../vtest/vtest make reg-tests


That may sound like a stupid question, but what makes you think that
~/tmp will actually result in a smaller path ? I mean ~ might very
well be "/home/automated-builds/travis/version-1.2.3.4/haproxy" on
the target system. Thus I think we're trying random locations until
it works :-/


I had no access to any travis environment when it has been told in 
previous mails that /tmp could not work, and /var/tmp could not either.

They were the first tested values.

Now that I have setup a travis account, I have just double checked, and 
contrary to what has been previously told, /tmp value for TMPDIR may 
make the reg tests work on OS X with travis.


So here is attached to this mail a better fix.


Fred.
>From dd2828071bc36375a485a7ab7d6d601d9ce729be Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Fri, 3 May 2019 19:16:02 +0200
Subject: [PATCH] BUILD: travis: TMPDIR replacement.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

TMPDIR default value may be too long to create UNIX sockets for the stats
used during the reg tests. Indeed vtest builds its temporary working directory
${tmpdir} variable from TMPDIR variable, with /tmp as value if not already set.
This is the case on Linux contrary to OS X which sets TMPDIR with a too much long
value.

With this path we revert the part of 88c63a6 commit which tried to shorten this
TMPDIR value modifying script/run-regtests.sh. Unfortunately this was not
sufficient. Furthermore this patch force TMPDIR to /tmp value for all the OS'es.

Thank you to Tim DÃ¼sterhus and Ilya for having helped on this issue.
---
 .travis.yml | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index f689fe982..be3207113 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -27,16 +27,10 @@ install:
   # Special flags due to: https://github.com/vtest/VTest/issues/12
   - make -C ../vtest FLAGS="-O2 -s -Wall"
 
-before_script:
-  # This is a fix for the super long TMPDIR on Mac making
-  # the unix socket path names exceed the maximum allowed
-  # length.
-  - sed -i'.original' '/TESTDIR=.*haregtests/s/haregtests-.*XX/regtest.XXX/' scripts/run-regtests.sh
-
 script:
   - make CC=$CC V=1 TARGET=$TARGET $FLAGS
   - ./haproxy -vv
-  - env VTEST_PROGRAM=../vtest/vtest make reg-tests
+  - env TMPDIR=/tmp VTEST_PROGRAM=../vtest/vtest make reg-tests
 
 after_failure:
   - |
-- 
2.11.0

Re: reg-tests are broken when running osx + openssl


On 5/3/19 5:35 PM, Frederic Lecaille wrote:

On 5/3/19 3:44 PM, Илья Шипицин wrote:



пт, 3 мая 2019 г. в 18:42, Tim Düsterhus <mailto:t...@bastelstu.be>>:


    Ilya,

    Am 03.05.19 um 15:39 schrieb Илья Шипицин:
 > when I played with enabling travis-ci, I tried to set TMPDIR
    directly,
 > however I was not lucky enough.
 > Later Tim added "sed" magic to .travis.yml
 >
 > personally, I do not understand why "sed" is better than
    assigning TMPDIR
 > directly.

    I did not try using TMPDIR=/tmp or something like that, because I
    thought there must be a reason why it's that strange long path.


I tried /tmp and /var/tmp
it seems that not any filesystem on osx can hold network socket (at 
least from my point of view)


try to create a working directory owned by the user which run the reg 
test :


    $ mkdir -p ~/tmp/
    $ TMPDIR=~/tmp make reg-tests


I confirm that with such a value everything work on all OS'es 
(https://travis-ci.com/haproxyFred/haproxy)


The attached patch should fix this issue.

Thank you Tim, Ilya.

Fred.
>From fc9decae9ec679038dc494ad612dd3eb144de408 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Fri, 3 May 2019 19:16:02 +0200
Subject: [PATCH] BUILD: travis: TMPDIR replacement.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

TMPDIR default value is too long especially on OSX systems.
We decided to shorten it for all the OS'es.

Thank you to Tim DÃ¼sterhus and Ilya for having helped on this issue.
---
 .travis.yml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/.travis.yml b/.travis.yml
index f689fe982..7475ad028 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -31,12 +31,12 @@ before_script:
   # This is a fix for the super long TMPDIR on Mac making
   # the unix socket path names exceed the maximum allowed
   # length.
-  - sed -i'.original' '/TESTDIR=.*haregtests/s/haregtests-.*XX/regtest.XXX/' scripts/run-regtests.sh
+  - mkdir ~/tmp
 
 script:
   - make CC=$CC V=1 TARGET=$TARGET $FLAGS
   - ./haproxy -vv
-  - env VTEST_PROGRAM=../vtest/vtest make reg-tests
+  - env TMPDIR=~/tmp VTEST_PROGRAM=../vtest/vtest make reg-tests
 
 after_failure:
   - |
-- 
2.11.0

Re: reg-tests are broken when running osx + openssl


On 5/3/19 3:44 PM, Илья Шипицин wrote:



пт, 3 мая 2019 г. в 18:42, Tim Düsterhus >:


Ilya,

Am 03.05.19 um 15:39 schrieb Илья Шипицин:
 > when I played with enabling travis-ci, I tried to set TMPDIR
directly,
 > however I was not lucky enough.
 > Later Tim added "sed" magic to .travis.yml
 >
 > personally, I do not understand why "sed" is better than
assigning TMPDIR
 > directly.

I did not try using TMPDIR=/tmp or something like that, because I
thought there must be a reason why it's that strange long path.


I tried /tmp and /var/tmp
it seems that not any filesystem on osx can hold network socket (at 
least from my point of view)


try to create a working directory owned by the user which run the reg test :

   $ mkdir -p ~/tmp/
   $ TMPDIR=~/tmp make reg-tests

Re: reg-tests are broken when running osx + openssl

On 5/3/19 1:34 PM, Tim Düsterhus wrote:

Fred,
Ilya,

Hello Tim,

Am 03.05.19 um 13:20 schrieb Frederic Lecaille:

About the test which fail, I would say that such errors are not
negligible :

Starting frontend GLOBAL: cannot change UNIX socket ownership
[/var/folders/nz/vv4_9tw56nv9k3tkvyszvwg8gn/T//regtest.zHu/

I believe this is an issue with the long TMPDIR that I tried to mitigate
with this: https://github.com/haproxy/haproxy/blob/master/.travis.yml#L34

With your patch, vtest is able to create the LOG files at the same place
$TMPDIR/ where the UNIX stats socket should be
created. So this does not interfere with the test.

While debugging I noticed that the validation did not properly account
for the temporary extension of the filename during start-up, causing
HAProxy to accept the filename during the check, but fail to set it up.
This leads to the misleading error message.

Yes, perhaps he UNIX stats socket filename is too long (I have found 104
max length for sun_path on Max OS X, 108 on Linux).

So, I propose you revert your fix, and try to find another ways to set
TMPDIR with a shorter value than the default one which is too long for
UNIX sockets. At least this is the correct way to change the working
directory for vtest.

For instance we have:

/var/folders/nz/vv4_9tw56nv9k3tkvyszvwg8gn/T//regtest.zHu/vtc.23058.0fa4d8bc/h1/stats.sock

which is 94 bytes long. Should work only if we do not add an ..tmp
extension bigger than 10 bytes. I guess this is not the case when the
PID is big. Now I understand why some test may pass.

I have also noted that there is a missing closing bracket in this log line:

*** h10.0 debug|[ALERT] 122/093540 (23139) : Starting frontend
GLOBAL: cannot change UNIX socket ownership
[/var/folders/nz/vv4_9tw56nv9k3tkvyszvwg8gn/T//regtest.zHu/

which is built like that:

snprintf(errmsg, errlen, "%s [%s]", msg, path);

with 100 as errlen value: "cannot change UNIX socket ownership
[/var/folders/nz/vv4_9tw56nv9k3tkvyszvwg8gn/T//regtest.zHu/" is
exactly a 100 bytes long string. So here the path for the UNIX socket is
truncated in the log.

So let's try with a shorter TMPDIR variable please. This should fix the
issue.

I did not get around to investigating this further and filing a bug
report, however.

Best regards
Tim Düsterhus

Re: reg-tests are broken when running osx + openssl


On 5/3/19 1:20 PM, Frederic Lecaille wrote:

So on OSX you should try to use/create a temporary working director 
where you have enough permissions to create a stats UNIX socket with 
0600 as permissions.


I meant you should try to create a temporary working directory for vtest 
using the TMPDIR environment variable, as follows for instance:


  $ mkdir ~/tmp/foo

  $ TMPDIR=~/tmp/foo make reg-tests 
reg-tests/http-capture/multiple_headers.vtc


## Preparing to run tests ##
Testing with haproxy version: 2.0-dev2-a48237-261
Target : linux2628
Options : +EPOLL -KQUEUE -MY_EPOLL -MY_SPLICE +NETFILTER +PCRE -PCRE_JIT 
-PCRE2 -PCRE2_JIT +POLL -PRIVATE_CACHE +THREAD -PTHREAD_PSHARED -REGPARM 
-STATIC_PCRE -STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT 
+CRYPT_H -VSYSCALL -GETADDRINFO +OPENSSL +LUA +FUTEX +ACCEPT4 
-MY_ACCEPT4 +ZLIB -SLZ +CPU_AFFINITY -TFO -NS +DL +RT -DEVICEATLAS 
-51DEGREES -WURFL -SYSTEMD -OBSOLETE_LINKER +PRCTL

## Gathering tests to run ##
  Add test: reg-tests/http-capture/multiple_headers.vtc
## Starting vtest ##
Testing with haproxy version: 2.0-dev2-a48237-261
#top  TEST reg-tests/http-capture/multiple_headers.vtc TIMED OUT 
(kill -9)
#top  TEST reg-tests/http-capture/multiple_headers.vtc FAILED 
(10.010) signal=9

1 tests failed, 0 tests skipped, 0 tests passed
## Gathering results ##
## Test case: reg-tests/http-capture/multiple_headers.vtc ##
## test results in: 
"/home/flecaille/tmp/foo/haregtests-2019-05-03_13-24-59.2P0ECZ/vtc.1327.1fe5daa1"

 c15.0 HTTP rx timeout (fd:9 5000 ms)
Makefile:971: recipe for target 'reg-tests' failed
make: *** [reg-tests] Error 1


As you can see the logs are now in /home/flecaille/tmp/foo (with ~ my 
home directory: /home/flecaille)


The LOG file is here: 
/home/flecaille/tmp/foo/haregtests-2019-05-03_13-24-59.2P0ECZ/vtc.1327.1fe5daa1/LOG


and the UNIX stats socket is here:

$ grep stats 
/home/flecaille/tmp/foo/haregtests-2019-05-03_13-24-59.2P0ECZ/vtc.1327.1fe5daa1/LOG 

 h 0.0 conf|\tstats socket 
"/home/flecaille/tmp/foo/haregtests-2019-05-03_13-24-59.2P0ECZ/vtc.1327.1fe5daa1/h/stats.sock" 
level admin mode 600

Re: reg-tests are broken when running osx + openssl


On 5/3/19 11:39 AM, Илья Шипицин wrote:

Hello,

I'm expanding openssl matrix.
here's failing build

https://travis-ci.org/chipitsine/haproxy-1/jobs/527683332


Hello Ilya,

In fact this has nothing to see with openssl. A lot of tests without any 
usage of TLS/SSL also fail.


There are a lot of HTTP rx which timed out.

Only these two tests passed:

   reg-tests/http-capture/multiple_headers.vtc
   reg-tests/spoe/wrong_init.vtc

but in these cases we do not have any log.

About the test which fail, I would say that such errors are not negligible :

Starting frontend GLOBAL: cannot change UNIX socket ownership 
[/var/folders/nz/vv4_9tw56nv9k3tkvyszvwg8gn/T//regtest.zHu/


I have simulated it with such a patch on Linux:

$ git diff src/proto_uxst.c
diff --git a/src/proto_uxst.c b/src/proto_uxst.c
index 980a22649..b5f945b9f 100644
--- a/src/proto_uxst.c
+++ b/src/proto_uxst.c
@@ -309,6 +309,10 @@ static int uxst_bind_listener(struct listener 
*listener, char *errmsg, int errle

goto err_unlink_temp;
}

+   err |= ERR_FATAL | ERR_ALERT;
+   msg = "cannot change UNIX socket ownership";
+   goto err_unlink_temp;
+
ready = 0;
ready_len = sizeof(ready);
if (getsockopt(fd, SOL_SOCKET, SO_ACCEPTCONN, , 
_len) == -1)



I got the same results as yours: lots of HTTP RX time out because 
haproxy exited unespectedly.


But in such a case on my PC only reg-tests/spoe/wrong_init.vtc succeeds.
I do not understand how reg-tests/http-capture/multiple_headers.vtc can 
succeed on your side.


Would be interesting to run it on OSX with this command:

$ make reg-tests reg-tests/http-capture/multiple_headers.vtc -- --debug


So on OSX you should try to use/create a temporary working director 
where you have enough permissions to create a stats UNIX socket with 
0600 as permissions.


And let's see if that fixes your issue.


Fred.

Re: reg-tests fail on FreeBSD 12.0

2019-04-30 Thread Frederic Lecaille


On 4/30/19 11:24 AM, Илья Шипицин wrote:

you are right.

let us exclude that particular test from freebsd (what your patch 
exactly does)


Ok Thank you Ilya.

Willy could you merge this patch if we decide to disable this reg test
on FreeBSD systems. It had already been fixed to make it succeed on a 
FreeBSD version I do not remember (see commit 9ffb88d). This issue came 
back with 12.0 version with a similar regex. So I think it is time to 
disabled this reg test for FreeBSD. Furthermore, it was originally 
dedicated to Linux.


If we do not decide to disable it on FreeBSD, we must rewrite the syslog 
message regexes to make them more permissive as with 9ffb88d commit.


Fred.





>From 0989af55e5a3d2d87defd64a68a78ff1057ad5db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Mon, 29 Apr 2019 16:10:12 +0200
Subject: [PATCH] REGTEST: Make this reg test be Linux specific.

This patch reverts 9ffb88 commit (REGTEST: Be less Linux specific with a syslog
regex.) and makes this script be Linux specific.
---
 reg-tests/checks/4be_1srv_smtpchk_httpchk_layer47errors.vtc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/reg-tests/checks/4be_1srv_smtpchk_httpchk_layer47errors.vtc b/reg-tests/checks/4be_1srv_smtpchk_httpchk_layer47errors.vtc
index ffd31235e..e3c959f16 100644
--- a/reg-tests/checks/4be_1srv_smtpchk_httpchk_layer47errors.vtc
+++ b/reg-tests/checks/4be_1srv_smtpchk_httpchk_layer47errors.vtc
@@ -1,6 +1,7 @@
 varnishtest "Check: smptchk option"
 feature ignore_unknown_macro
 
+#EXCLUDE_TARGETS=freebsd,osx,generic
 #REGTEST_TYPE=slow
 
 barrier b cond 3
@@ -29,7 +30,7 @@ syslog S3 -level notice {
 recv
 expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be3 started"
 recv
-expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be3/srv3 failed, reason: Layer4 .* check duration: [[:digit:]]+ms, status: 0/1 DOWN."
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be3/srv3 failed, reason: Layer4 connection problem, info: \"General socket error \\(Network is unreachable\\)\", check duration: [[:digit:]]+ms, status: 0/1 DOWN."
 } -start
 
 syslog S4 -level notice {
-- 
2.11.0

Re: reg-tests fail on FreeBSD 12.0

2019-04-30 Thread Frederic Lecaille

On 4/30/19 10:04 AM, Илья Шипицин wrote:

Hello, Frederic

I have applied only that part

  barrier b cond 3
@@ -29,7 +30,7 @@ syslog S3 -level notice {
  recv
  expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be3 started"
  recv
-    expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be3/srv3 
failed, reason: Layer4 .* check duration: [[:digit:]]+ms, status: 0/1 DOWN."
+    expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be3/srv3 
failed, reason: Layer4 connection problem, info: \"General socket error 
\\(Network is unreachable\\)\", check duration: [[:digit:]]+ms, status: 
0/1 DOWN."

  } -start

it works, test is green now (on freebsd)

https://cirrus-ci.com/task/6252507322908672

пн, 29 апр. 2019 г. в 19:14, Frederic Lecaille <mailto:flecai...@haproxy.com>>:

On 4/29/19 3:56 PM, Илья Шипицин wrote:
 > well, in cirrus-ci we can choose several freebsd images. I just
picked
 > up the most recent one.
 >
 > I'll try older images soon.
 >
 > actually, there are several options
 >
 > 1) add special "ignore" to those tests (can we ignore certain
tests, for

Well this reg test was originally Linux specific.

With the patch attached we can make it be Linux specific again.

Fred.

Hello Ilya,

I am not sure to understand everything.

In fact the patch I sent is supposed to disable the reg test on freebsd 
because it also restores a Linux specific regex on syslog messages. The 
reg test should not be run on FreeBSD, thanks to this patch. The part of 
the patch you applied is Linux specific. If you do not take the other 
part of the patch, the reg test is not disabled on freebsd. So it should 
fail contrary to what you reported. 
https://cirrus-ci.com/build/6289311702974464 does not demonstrate the 
reg test succeeds. Isn't this  only a build report? If I use the task ID 
6252507322908672 and have a look at the log here:

https://api.cirrus-ci.com/v1/task/6252507322908672/logs/main.log

I do not see any reg test result.

Fred.

Re: reg-tests fail on FreeBSD 12.0

2019-04-29 Thread Frederic Lecaille


On 4/29/19 3:56 PM, Илья Шипицин wrote:
well, in cirrus-ci we can choose several freebsd images. I just picked 
up the most recent one.


I'll try older images soon.

actually, there are several options

1) add special "ignore" to those tests (can we ignore certain tests, for 


Well this reg test was originally Linux specific.

With the patch attached we can make it be Linux specific again.


Fred.
>From 0989af55e5a3d2d87defd64a68a78ff1057ad5db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Mon, 29 Apr 2019 16:10:12 +0200
Subject: [PATCH] REGTEST: Make this reg test be Linux specific.

This patch reverts 9ffb88 commit (REGTEST: Be less Linux specific with a syslog
regex.) and makes this script be Linux specific.
---
 reg-tests/checks/4be_1srv_smtpchk_httpchk_layer47errors.vtc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/reg-tests/checks/4be_1srv_smtpchk_httpchk_layer47errors.vtc b/reg-tests/checks/4be_1srv_smtpchk_httpchk_layer47errors.vtc
index ffd31235e..e3c959f16 100644
--- a/reg-tests/checks/4be_1srv_smtpchk_httpchk_layer47errors.vtc
+++ b/reg-tests/checks/4be_1srv_smtpchk_httpchk_layer47errors.vtc
@@ -1,6 +1,7 @@
 varnishtest "Check: smptchk option"
 feature ignore_unknown_macro
 
+#EXCLUDE_TARGETS=freebsd,osx,generic
 #REGTEST_TYPE=slow
 
 barrier b cond 3
@@ -29,7 +30,7 @@ syslog S3 -level notice {
 recv
 expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be3 started"
 recv
-expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be3/srv3 failed, reason: Layer4 .* check duration: [[:digit:]]+ms, status: 0/1 DOWN."
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be3/srv3 failed, reason: Layer4 connection problem, info: \"General socket error \\(Network is unreachable\\)\", check duration: [[:digit:]]+ms, status: 0/1 DOWN."
 } -start
 
 syslog S4 -level notice {
-- 
2.11.0

Re: reg-tests fail on FreeBSD 12.0

2019-04-29 Thread Frederic Lecaille


On 4/29/19 2:18 PM, Frederic Lecaille wrote:

On 4/27/19 1:28 AM, Илья Шипицин wrote:

please have a look


build script:
https://github.com/chipitsine/haproxy-1/commit/6739f36463dc9e82eb65a9fa8353a42128403f0c 



build log (error):
https://api.cirrus-ci.com/v1/task/5196617547251712/logs/main.log


any idea ?


thanks!
Ilya Shipicin


Hello Ilya,

In fact not in use ports are not handled the same way between Linux and 
FreeBSD. On Linux systems connections to not in use port lead to TCP RST 
contrary to FreeBSD (timeout).


I remember having fixed one time this script to make it succeed on a 
version of FreeBSD but I do not remember which one (11 I guess) : see 
commit 9ffb88d. This is why I am surprised to have again such an error 
with this script on FreeBSD. Perhaps I have missed something.


I think we should revert 9ffb88d commit and flag this script as being 
Linux specific and create a new one specific for FreeBSD.


Perhaps the TCP blackhole is enabled since 12.0 version?

see https://www.freebsd.org/cgi/man.cgi?query=blackhole.

Re: reg-tests fail on FreeBSD 12.0

2019-04-29 Thread Frederic Lecaille


On 4/27/19 1:28 AM, Илья Шипицин wrote:

please have a look


build script:
https://github.com/chipitsine/haproxy-1/commit/6739f36463dc9e82eb65a9fa8353a42128403f0c

build log (error):
https://api.cirrus-ci.com/v1/task/5196617547251712/logs/main.log


any idea ?


thanks!
Ilya Shipicin


Hello Ilya,

In fact not in use ports are not handled the same way between Linux and 
FreeBSD. On Linux systems connections to not in use port lead to TCP RST 
contrary to FreeBSD (timeout).


I remember having fixed one time this script to make it succeed on a 
version of FreeBSD but I do not remember which one (11 I guess) : see 
commit 9ffb88d. This is why I am surprised to have again such an error 
with this script on FreeBSD. Perhaps I have missed something.


I think we should revert 9ffb88d commit and flag this script as being 
Linux specific and create a new one specific for FreeBSD.



Fred.

Re: [PATCH] FEATURE/MEDIUM: enable travis-ci builds

2019-04-17 Thread Frederic Lecaille


On 4/16/19 8:17 PM, Илья Шипицин wrote:

+  - make CC=$CC V=1 TARGET=$TARGET
+  - export PATH=${PATH}:${PWD}/VTest
+  - export VTEST_PROGRAM="VTest/vtest -v" # "VTest/vtest -v"


Just to let you note that if you build vtest in the same directory as 
haproxy ones



+  - make reg-tests


with this command you will run all the tests for vtest itself present in
VTest/tests directory.


Fred.

Re: running reg-test when haproxy is built without USE_OPENSSL

2019-04-17 Thread Frederic Lecaille


On 4/17/19 9:01 AM, Илья Шипицин wrote:

Hello,


Hi,

when playing with travis-ci build matrix, I see that the following tests 
fail


reg-tests/ssl/*

if haproxy is built without ssl.
also, I've found that lua tests are guarded with #REQUIRE_OPTIONS=LUA


should we guard ssl test in the same way ?


Yes we should.

Fred.

vtest update

2019-03-06 Thread Frederic Lecaille


Hello ML,

We have recently modified some reg tests which require an update for 
vtest, especially these ones:


reg-tests/peers/s_basic_sync.vtc   (added)
reg-tests/peers/s_tls_basic_sync.vtc   (added)
reg-tests/http-messaging/h0.vtc(modified)

So, if some reg tests fail do not hesitate to update your vtest program.

Regards,

Fred.

Re: Compilation fails on OS-X

2019-02-14 Thread Frederic Lecaille


On 2/14/19 3:12 PM, Patrick Hemmer wrote:



On 2019/2/14 08:20, Frederic Lecaille wrote:

On 2/14/19 1:32 PM, Frederic Lecaille wrote:

On 2/13/19 7:30 PM, Patrick Hemmer wrote:



On 2019/2/13 10:29, Olivier Houchard wrote:

Hi Patrick,

On Wed, Feb 13, 2019 at 10:01:01AM -0500, Patrick Hemmer wrote:

On 2019/2/13 09:40, Aleksandar Lazic wrote:

Am 13.02.2019 um 14:45 schrieb Patrick Hemmer:
Trying to compile haproxy on my local machine for testing 
purposes and am

running into the following:

Which compiler do you use?

# gcc -v
Configured with: 
--prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/usr/include/c++/4.2.1

Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin 




 # make TARGET=osx
 src/proto_http.c:293:1: error: argument to 'section' 
attribute is not
valid for this target: mach-o section specifier requires a 
segment and section

separated by a comma
 DECLARE_POOL(pool_head_http_txn, "http_txn", 
sizeof(struct http_txn));

 ^
 include/common/memory.h:128:2: note: expanded from 
macro 'DECLARE_POOL'

 REGISTER_POOL(, name, size)
 ^
 include/common/memory.h:123:2: note: expanded from 
macro 'REGISTER_POOL'
 INITCALL3(STG_POOL, 
create_pool_callback, (ptr), (name),

(size))
 ^
 include/common/initcall.h:102:2: note: expanded from 
macro 'INITCALL3'
 _DECLARE_INITCALL(stage, __LINE__, 
function, arg1, arg2,

arg3)
 ^
 include/common/initcall.h:78:2: note: expanded from macro
'_DECLARE_INITCALL'
__DECLARE_INITCALL(__VA_ARGS__)
 ^
 include/common/initcall.h:65:42: note: expanded from macro
'__DECLARE_INITCALL'
__attribute__((__used__,__section__("init_"#stg))) = \



Issue occurs on master, and the 1.9 branch

-Patrick
Does the (totally untested, because I have no Mac to test) patch 
works for

you ?


Unfortunately not. Just introduces a lot of new errors:


 In file included from src/ev_poll.c:22:
 In file included from include/common/hathreads.h:26:
 include/common/initcall.h:134:22: error: expected ')'
 DECLARE_INIT_SECTION(STG_PREPARE);
                                          ^
 include/common/initcall.h:134:1: note: to match this '('
 DECLARE_INIT_SECTION(STG_PREPARE);
 ^
 include/common/initcall.h:124:82: note: expanded from macro 
'DECLARE_INIT_SECTION'
                 extern __attribute__((__weak__)) const struct 
initcall *__start_init_##stg __asm("section$start$__DATA$" stg); \

^


Try to use -E in place of -c option of your compiler to stop after 
having preprocessed the code. Then have a look to how the code of 
src/ev_poll.c was preprocessed.


This should help.

Fred.


As this sounds to be a preprocessing issue, and to have a look to how 
the code is preprocessed for Apple we can invert the two #ifdef 
__APPLE__  condition of Olivier's patch to use the same preprocessor 
commands on a Linux system.



Here is the code after having preprocessed it:


# 134 "include/common/initcall.h"
extern __attribute__((__weak__)) const struct initcall 
*__start_init_STG_PREPARE __asm("section$start$__DATA$" STG_PREPARE); 
extern __attribute__((__weak__)) const struct initcall 
*__stop_init_STG_PREPARE __asm("section$end$__DATA$" STG_PREPARE);
extern __attribute__((__weak__)) const struct initcall 
*__start_init_STG_LOCK __asm("section$start$__DATA$" STG_LOCK); extern 
__attribute__((__weak__)) const struct initcall *__stop_init_STG_LOCK 
__asm("section$end$__DATA$" STG_LOCK);
extern __attribute__((__weak__)) const struct initcall 
*__start_init_STG_ALLOC __asm("section$start$__DATA$" STG_ALLOC); 
extern __attribute__((__weak__)) const struct initcall 
*__stop_init_STG_ALLOC __asm("section$end$__DATA$" STG_ALLOC);
extern __attribute__((__weak__)) const struct initcall 
*__start_init_STG_POOL __asm("section$start$__DATA$" STG_POOL); extern 
__attribute__((__weak__)) const struct initcall *__stop_init_STG_POOL 
__asm("section$end$__DATA$" STG_POOL);
extern __attribute__((__weak__)) const struct initcall 
*__start_init_STG_REGISTER __asm("section$start$__DATA$" 
STG_REGISTER); extern __attribute__((__weak__)) const struct initcall 
*__stop_init_STG_REGISTER __asm("section$end$__DATA$" STG_REGISTER);
extern __attribute__((__weak__)) const struct initcall 
*__start_init_STG_INIT __asm("section$start$__DATA$" STG_INIT); extern 
__attribute__((__weak__)) const struct initcall *__stop_init_STG_INIT 
__asm("section$end$__DATA$" STG_INIT);




should be I guess

e

Re: Compilation fails on OS-X

2019-02-14 Thread Frederic Lecaille


On 2/14/19 1:32 PM, Frederic Lecaille wrote:

On 2/13/19 7:30 PM, Patrick Hemmer wrote:



On 2019/2/13 10:29, Olivier Houchard wrote:

Hi Patrick,

On Wed, Feb 13, 2019 at 10:01:01AM -0500, Patrick Hemmer wrote:

On 2019/2/13 09:40, Aleksandar Lazic wrote:

Am 13.02.2019 um 14:45 schrieb Patrick Hemmer:
Trying to compile haproxy on my local machine for testing purposes 
and am

running into the following:

Which compiler do you use?

# gcc -v
Configured with: 
--prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/usr/include/c++/4.2.1

Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin 




 # make TARGET=osx
 src/proto_http.c:293:1: error: argument to 'section' 
attribute is not
valid for this target: mach-o section specifier requires a segment 
and section

separated by a comma
 DECLARE_POOL(pool_head_http_txn, "http_txn", 
sizeof(struct http_txn));

 ^
 include/common/memory.h:128:2: note: expanded from macro 
'DECLARE_POOL'

 REGISTER_POOL(, name, size)
 ^
 include/common/memory.h:123:2: note: expanded from macro 
'REGISTER_POOL'
 INITCALL3(STG_POOL, create_pool_callback, 
(ptr), (name),

(size))
 ^
 include/common/initcall.h:102:2: note: expanded from 
macro 'INITCALL3'
 _DECLARE_INITCALL(stage, __LINE__, 
function, arg1, arg2,

arg3)
 ^
 include/common/initcall.h:78:2: note: expanded from macro
'_DECLARE_INITCALL'
 __DECLARE_INITCALL(__VA_ARGS__)
 ^
 include/common/initcall.h:65:42: note: expanded from macro
'__DECLARE_INITCALL'
__attribute__((__used__,__section__("init_"#stg))) =   \



Issue occurs on master, and the 1.9 branch

-Patrick
Does the (totally untested, because I have no Mac to test) patch 
works for

you ?


Unfortunately not. Just introduces a lot of new errors:


 In file included from src/ev_poll.c:22:
 In file included from include/common/hathreads.h:26:
 include/common/initcall.h:134:22: error: expected ')'
 DECLARE_INIT_SECTION(STG_PREPARE);
                                          ^
 include/common/initcall.h:134:1: note: to match this '('
 DECLARE_INIT_SECTION(STG_PREPARE);
 ^
 include/common/initcall.h:124:82: note: expanded from macro 
'DECLARE_INIT_SECTION'
                 extern __attribute__((__weak__)) const struct 
initcall *__start_init_##stg __asm("section$start$__DATA$" stg); \

^


Try to use -E in place of -c option of your compiler to stop after 
having preprocessed the code. Then have a look to how the code of 
src/ev_poll.c was preprocessed.


This should help.

Fred.


As this sounds to be a preprocessing issue, and to have a look to how 
the code is preprocessed for Apple we can invert the two #ifdef 
__APPLE__  condition of Olivier's patch to use the same preprocessor 
commands on a Linux system.



Here is the code after having preprocessed it:


# 134 "include/common/initcall.h"
extern __attribute__((__weak__)) const struct initcall 
*__start_init_STG_PREPARE __asm("section$start$__DATA$" STG_PREPARE); 
extern __attribute__((__weak__)) const struct initcall 
*__stop_init_STG_PREPARE __asm("section$end$__DATA$" STG_PREPARE);
extern __attribute__((__weak__)) const struct initcall 
*__start_init_STG_LOCK __asm("section$start$__DATA$" STG_LOCK); extern 
__attribute__((__weak__)) const struct initcall *__stop_init_STG_LOCK 
__asm("section$end$__DATA$" STG_LOCK);
extern __attribute__((__weak__)) const struct initcall 
*__start_init_STG_ALLOC __asm("section$start$__DATA$" STG_ALLOC); extern 
__attribute__((__weak__)) const struct initcall *__stop_init_STG_ALLOC 
__asm("section$end$__DATA$" STG_ALLOC);
extern __attribute__((__weak__)) const struct initcall 
*__start_init_STG_POOL __asm("section$start$__DATA$" STG_POOL); extern 
__attribute__((__weak__)) const struct initcall *__stop_init_STG_POOL 
__asm("section$end$__DATA$" STG_POOL);
extern __attribute__((__weak__)) const struct initcall 
*__start_init_STG_REGISTER __asm("section$start$__DATA$" STG_REGISTER); 
extern __attribute__((__weak__)) const struct initcall 
*__stop_init_STG_REGISTER __asm("section$end$__DATA$" STG_REGISTER);
extern __attribute__((__weak__)) const struct initcall 
*__start_init_STG_INIT __asm("section$start$__DATA$" STG_INIT); extern 
__attribute__((__weak__)) const struct initcall *__stop_init_STG_INIT 
__asm("section$end$__DATA$" STG_INIT);




should be I guess

extern __attribute__((__weak__)) const struct initcall 
*__start_ini

Re: Compilation fails on OS-X

2019-02-14 Thread Frederic Lecaille


On 2/13/19 7:30 PM, Patrick Hemmer wrote:



On 2019/2/13 10:29, Olivier Houchard wrote:

Hi Patrick,

On Wed, Feb 13, 2019 at 10:01:01AM -0500, Patrick Hemmer wrote:

On 2019/2/13 09:40, Aleksandar Lazic wrote:

Am 13.02.2019 um 14:45 schrieb Patrick Hemmer:

Trying to compile haproxy on my local machine for testing purposes and am
running into the following:

Which compiler do you use?

# gcc -v
Configured with: 
--prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 9.0.0 (clang-900.0.39.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin


 # make TARGET=osx
 src/proto_http.c:293:1: error: argument to 'section' attribute is not
valid for this target: mach-o section specifier requires a segment and section
separated by a comma
 DECLARE_POOL(pool_head_http_txn, "http_txn", sizeof(struct http_txn));
 ^
 include/common/memory.h:128:2: note: expanded from macro 'DECLARE_POOL'
 REGISTER_POOL(, name, size)
 ^
 include/common/memory.h:123:2: note: expanded from macro 
'REGISTER_POOL'
 INITCALL3(STG_POOL, create_pool_callback, (ptr), 
(name),
(size))
 ^
 include/common/initcall.h:102:2: note: expanded from macro 'INITCALL3'
 _DECLARE_INITCALL(stage, __LINE__, function, arg1, 
arg2,
arg3)
 ^
 include/common/initcall.h:78:2: note: expanded from macro
'_DECLARE_INITCALL'
 __DECLARE_INITCALL(__VA_ARGS__)
 ^
 include/common/initcall.h:65:42: note: expanded from macro
'__DECLARE_INITCALL'

__attribute__((__used__,__section__("init_"#stg))) =   \




Issue occurs on master, and the 1.9 branch

-Patrick

Does the (totally untested, because I have no Mac to test) patch works for
you ?


Unfortunately not. Just introduces a lot of new errors:


     In file included from src/ev_poll.c:22:
     In file included from include/common/hathreads.h:26:
     include/common/initcall.h:134:22: error: expected ')'
     DECLARE_INIT_SECTION(STG_PREPARE);
                                              ^
     include/common/initcall.h:134:1: note: to match this '('
     DECLARE_INIT_SECTION(STG_PREPARE);
     ^
     include/common/initcall.h:124:82: note: expanded from macro 
'DECLARE_INIT_SECTION'
                     extern __attribute__((__weak__)) const struct 
initcall *__start_init_##stg __asm("section$start$__DATA$" stg); \

^


Try to use -E in place of -c option of your compiler to stop after 
having preprocessed the code. Then have a look to how the code of 
src/ev_poll.c was preprocessed.


This should help.

Fred.

Re: reg-tests situation in haproxy 1.8

2019-01-21 Thread Frederic Lecaille


On 1/19/19 8:53 AM, Willy Tarreau wrote:

Hi Lukas,

On Fri, Jan 18, 2019 at 12:43:34PM +0100, Lukas Tribus wrote:

Hello,


currently we have 4 reg-tests in haproxy-1.8, backported due to the
actual bugfix commit, which included a test. We also have a broken
symbolic link in reg-tests/lua/common.pem, which causes at least some
confusion [1].


This is getting dirty :-/


We don't have any test infrastructure in haproxy-1.8 (Makefile,
reg-tests/README) afaik.

So my question is, where do we go from here? Dropping them all, and
remove the test part in future backports? Or backport the actual
infrastructure so that 1.8 can be tested?


I was interested in backporting them to 1.8 once we have more experience
with them and they're better organized, so that we avoid backporting
reorg patches. I'd say we've made quite some progress now and we could
possibly backport them. But I wouldn't be surprised if we'd soon rename
many of them again since the relation between the level and the prefix
letter has to be looked up into the makefile each time, so probably this
is something we should improve.


Note that a "reg-tests-help" makefile target dump the list of LEVELs:



$ make reg-tests-help

To launch the reg tests for haproxy, first export to your environment 
VTEST_PROGRAM variable to point to your vtest program:

$ export VTEST_PROGRAM=/opt/local/bin/vtest
or
$ setenv VTEST_PROGRAM /opt/local/bin/vtest

The same thing may be done to set your haproxy program with 
HAPROXY_PROGRAM but with ./haproxy as default value.


To run all the tests:
$ make reg-tests

You can also set the programs to be used on the command line:
$ VTEST_PROGRAM=<...> HAPROXY_PROGRAM=<...> make reg-tests

To run tests with specific levels:
$ LEVEL=1,3,4   make reg-tests  #list of levels
$ LEVEL=1-3,5-6 make reg-tests  #list of range of levels

About the levels:
LEVEL 1 scripts are dedicated to pure haproxy compliance tests 
(prefixed with 'h' letter).

LEVEL 2 scripts are slow scripts (prefixed with 's' letter).
LEVEL 3 scripts are low interest scripts (prefixed with 'l' letter).
LEVEL 4 scripts are in relation with bugs they help to reproduce 
(prefixed with 'b' letter).
LEVEL 5 scripts are scripts triggering known broken behaviors for 
which there is still no fix (prefixed with 'k' letter).
LEVEL 6 scripts are experimental, typically used to develop new 
scripts (prefixed with 'e' lettre).




On my side I always run all the VTC files. When I add a new reg test, it 
can be tested like that without using LEVEL:


$ make reg-tests 


We could set the level with strings:

h*.vtc -> haproxy
s*.vtc -> slow
l*.vtc -> low   (perhaps this one should be removed).
b*.vtx -> bug
k*.vtc -> broken
e*.vtc -> exp

only list of levels could be permitted:

$ LEVEL=haproxy,bug make reg-tests ...

As there is no more level notion here, perhaps we should rename LEVEL 
environment variable to VTC_TYPES, REGTEST_TYPES or something else.

Re: reg-tests situation in haproxy 1.8

2019-01-21 Thread Frederic Lecaille


On 1/19/19 8:53 AM, Willy Tarreau wrote:

Hi Lukas,

On Fri, Jan 18, 2019 at 12:43:34PM +0100, Lukas Tribus wrote:

Hello,


currently we have 4 reg-tests in haproxy-1.8, backported due to the
actual bugfix commit, which included a test. We also have a broken
symbolic link in reg-tests/lua/common.pem, which causes at least some
confusion [1].


This is getting dirty :-/


We don't have any test infrastructure in haproxy-1.8 (Makefile,
reg-tests/README) afaik.

So my question is, where do we go from here? Dropping them all, and
remove the test part in future backports? Or backport the actual
infrastructure so that 1.8 can be tested?


I was interested in backporting them to 1.8 once we have more experience
with them and they're better organized, so that we avoid backporting
reorg patches. I'd say we've made quite some progress now and we could
possibly backport them. But I wouldn't be surprised if we'd soon rename
many of them again since the relation between the level and the prefix
letter has to be looked up into the makefile each time, so probably this
is something we should improve.

Over time I also find that purely numeric tests names are not *that*
convenient and as the mechanism develops, it will even cause more
confusion because multiple people will propose tests with a similar
name, either to document or reproduce an issue, or just because they
want to complete the regtests. And when reading an error report from
vtest, it is quite difficult to figure what was the original test
since we have many identical names in different directories. I see
that Pieter has already migrated to using fully descriptive names in
his new tests, which is probably what we should do.


I propose this renaming (after having modified a "tree" command output, 
the new names follow the semi-colon characters):


$ tree reg-tests
reg-tests
├── cache
│   └── h0.vtc : h_basic.vtc
├── checks
│   ├── common.pem -> ../ssl/common.pem
│   ├── s0.vtc : s_4be_1srv_health_checks.vtc
│   ├── s1.vtc : s_1be_40srv_odd_health_checks.vtc
│   ├── s2.vtc : s_40be_2srv_odd_health_checks.vtc
│   ├── s3.vtc : s_4be_1srv_smtpchk_httpchk_layer47errors.vtc
│   └── s4.vtc : s_tls_health_checks.vtc
├── compression
│   ├── common.pem -> ../ssl/common.pem
│   ├── h0.vtc : h_basic.vtc
│   ├── s0.lua
│   └── s0.vtc : h_lua_validation.vtc
├── connection
│   ├── b0.vtc : b_proxy_protocol_random_fail.vtc
│   ├── common.pem -> ../ssl/common.pem
│   └── h1.vtc : h_dispatch.vtc
├── http-capture
│   └── h0.vtc : h_multiple_headers.vtc
├── http-cookies
│   └── h0.vtc : h_cookie_insert_indirect.vtc
├── http-messaging
│   ├── h0.vtc : h_h1_to_h1.vtc
│   ├── h2.vtc : h_h2_to_h1.vtc
│   └── h3.vtc : h_http_request_buffer.vtc
├── http-rules
│   ├── b0.map
│   ├── b0.vtc : b_map_regm_with_backref.vtc
│   ├── h0.vtc : h_h1_to_h1c.vtc
│   ├── h1.vtc : h_h1or2_to_h1c.vtc
│   ├── h2.map
│   ├── h2.vtc : h_converters_ipmask_concat_strcmp_field_word.vtc
│   ├── h3-be.map
│   ├── h3.map
│   └── h3.vtc : h_map_redirect.vtc
├── log
│   └── b0.vtc : b_wrong_ip_port_logging.vtc
├── lua
│   ├── b0.lua
│   ├── b0.vtc : b_wrong_types_usage.vtc
│   ├── b1.lua
│   ├── b1.vtc : b_bad_http_clt_req_duration.vtc
│   ├── b2.lua
│   ├── b2_print_r.lua
│   ├── b2.vtc : b_txn_get_priv.vtc
│   ├── b3.lua
│   ├── b3.vtc : b_close_wait_lf.vtc
│   ├── common.pem -> ../ssl/common.pem
│   ├── h1.lua
│   ├── h1.vtc : h_txn_get_privv.vtc
│   ├── h2.lua
│   └── h2.vtc : h_lua_socket.vtc
├── mailers
│   ├── k_healthcheckmail.lua
│   └── k_healthcheckmail.vtc
├── peers
├── README
├── seamless-reload
│   └── b0.vtc : b_abns_socket.vtc
├── server
│   └── b0.vtc : b_cli_set_fdqn.vtc
├── spoe
│   └── b0.vtc : b_wrong_init.vtc
├── ssl
│   ├── b0.vtc : b_wrong_ctx_storage.vtc
│   ├── common.pem
│   └── README
├── stick-table
│   ├── b0.vtc : b_unknown_key.vtc
│   └── b1.vtc : b_converteers_ref_cnt_never_dec.vtc
└── webstats
└── h_webstats-scope-and-post-change.vtc

18 directories, 55 files


If agreed, I will provide a patch.


Fred.

Re: [PATCH 10/10] DOC: peers: SSL/TLS documentation for "peers"

2019-01-14 Thread Frederic Lecaille


On 1/14/19 2:56 PM, Willy Tarreau wrote:

Hi Fred,

first, thanks for reviving this!

On Fri, Jan 11, 2019 at 02:52:24PM +0100, flecai...@haproxy.com wrote:

+bind [param*]
+  Defines the binding parameters of the local peer of this "peers" section.
+  To avoid some redundancy, and as the  and  parameters
+  are already provided on "peer" (or "server") lines, they are not supported
+  by "bind" keyword in "peers" sections.
+

(...)

+   Example:
+ peers mypeers
+ bind ssl crt mycerts/pem
+ default-server ssl verify none
+ server hostA  127.0.0.10:1
+ server hostB  127.0.0.11:10001


Just thinking loud, I find this a bit confusing : "bind" usually is
followed by an address to bind to. And it's even wider than just the
haproxy culture. Here from what I'm seeing you're using it exactly
like "default-server", i.e. you can pass all default settings but not
the address. Thus I think that having a "default-bind" directive would
remove this confusion.


+  Note: "peer" keyword may transparently be replaced by "server" keyword (see
+  "server" keyword explanation below).
+
+server  : [param*]
+  As previously mentionned, "peer" keyword may be replaced by "server" keyword
+  with a support for all "server" parameters found in 5.2 paragraph.
+  Some of these parameters are irrelevant for "peers" sections.


Same here, if "server" also creates a listening address, it's quite
confusing in my opinion.


Yes, this is because the "peers" configuration are supposed to be
duplicated without on each haproxy peer. I agree that
"server" should only means "remote peer". It is confusing for the local
peer. Peers are remote or local, contrary to servers which are only
remote peers.


And this makes me think a bit further. I remember some old discussions
where we were saying that the main problem posed by peers is that they
are forcibly symmetrical ; you cannot use them on a dynamic IP address
or on a set of IP addresses for example because you are not allowed to
put 0.0.0.0 here as it also serves as a destination address. You cannot
use a unix socket nor 127.0.0.1 either, just like it's not possible to
listen both to IPv4 and IPv6 addresses.


yes, the peers section configurations are identical on each peer 
belonging to the section.



And I think that your "bind" + "server" options could solve this in a
very elegant way : what about having "bind" always set the listening
address and "server" always set only the target address ? In this case
we could simply handle the migration by making it an error to have both
"bind" and "peer". And thinking about it, I feel like that's a discussion
we already had in the past.


Ok.


Thus I think we could end up with this :

First step :
   - "peer" does what it currently does, i.e. set both the bind and the
  target address ;
   - "default-server" applies to the server part of the peers
   - "default-bind" applies to the bind part of the peers
   => that's what you did modulo the last option's naming

Then we add this :
   - "bind" only sets the bind address and bind options ;
   - "server" only sets target addresses and server options ;

And this will also solve the problem of testing peers with vtest, since
this time they will work *exactly* like real bind+servers with their own
addresses :-)

What do you think ?


I think that all this makes sense as always ;)
I will send a new series of patches for these modifications asap.

Re: [PATCH] REG-TEST: mailers: add new test for 'mailers' section

2019-01-11 Thread Frederic Lecaille


On 1/11/19 12:35 AM, Cyril Bonté wrote:

Hi all,

Le 08/01/2019 à 10:06, Willy Tarreau a écrit :

On Tue, Jan 08, 2019 at 09:31:22AM +0100, Frederic Lecaille wrote:
Indeed this script could worked with a short mailer timeout before 
af4021e6
commit. Another git bisect shows that 53216e7d introduced the email 
bombing

issue.

Note that 33a09a5f refers to 53216e7d commit.

I am not sure this can help.


Sure it helps, at least to know whom to ping :-)


Well, from what I've seen with a small test, I've a different conclusion 
about the commit which introduced the issue. It looks to have been 
introduced earlier with commit 0108bb3e4 "MEDIUM: mailers: Init alerts 
during conf parsing and refactor their processing"

http://git.haproxy.org/?p=haproxy.git;a=commit;h=0108bb3e4


You are true.
The feature was broken by af4021e6 fixed by 53216e7d which made
the bug occur again.

Thanks Cyril.

Fred.

Re: [PATCH 1/1] REGTEST: "capture (request|response)" regtest.


On 1/9/19 10:12 AM, Willy Tarreau wrote:

On Tue, Jan 08, 2019 at 10:24:16AM +0100, flecai...@haproxy.com wrote:

  reg-tests/http-capture/h0.vtc | 92 +++


Nice one, thanks Fred, now merged!

I'd be careful regarding expectations on log lines about stuff
that may evolve over time like the size below :


+expect ~ "[^:\\[ ]\\[${h_pid}\\]: .* .* fe be/srv .* 200 17641 - -  .* .* 
{HPhx8n59qjjNBLjP} {htb56qDdCcbRVTfS} \"GET / HTTP/1\\.1\""

 ^

Since haproxy logs the exact byte count it received including headers,
and the status line, this may easily vary over time with minor changes
to varnishtest or to haproxy's muxes. I think that for such ones where
the exact could is neither predicted nor important, using a regex with
the order of magnitude should be enough and more robust over time (eg:
1 followed by 4 digits).


Yes, I agree. But I am curious to see when and the reason why this reg
test will be broken ;)

Fred.

Re: [RFC PATCH] couple of reg-tests


On 1/9/19 3:22 PM, Jarno Huuskonen wrote:

Hello Frederic,

On Mon, Jan 07, Frederic Lecaille wrote:


reg-tests/http-rules/h3.vtc fails on my side due to a typo in
the regex with this error:

 h10.0 CLI regexp error: 'missing opening brace after \o'
(@48) (^0x[a-f0-9]+ example\.org
https://www\.example.\org\n0x[a-f0-9]+ subdomain\.example\.org
https://www\.subdomain\.example\.org\n$)

.\org shoulb be replaced by \.org

Could you check on your side why you did not notice this issue please?


For some reason the buggy regex works for me, maybe it depends on
pcre version.
My varnishtest links to centos7 default pcre (pcre-8.32-17.el7.x86_64).


Not that weird. This POSIX is not supported

 9.3.2 BRE Ordinary Characters

An ordinary character is a BRE that matches itself: any character in the 
supported character set, except for the BRE special characters listed in 
BRE Special Characters.


The interpretation of an ordinary character preceded by a backslash ( 
'\' ) is undefined, except for:


The characters ')', '(', '{', and '}'

The digits 1 to 9 inclusive (see BREs Matching Multiple Characters)

A character inside a bracket expression

http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html


After checking this issue we will merge your patches. Great work!


I'm attaching the patches again, with fixed regex in h3.vtc.
The patches are for recent 2.0dev.

Should reg-tests/README default to [-Dno-htx='#'] instead of -Dno-htx= ?


Perhaps [-Dno-htx=[#]] is even better as the # here is optional? I do 
not care on my side.


Do not modify anymore your patch for that.

Anybody to merge Jarno's patches?

Thank you for replying Jarno.

Fred.

Re: [PATCH] REGTEST: filters: add compression test


On 1/9/19 10:43 AM, Frederic Lecaille wrote:

On 1/8/19 11:25 PM, PiBa-NL wrote:

Hi Frederic,


Hi Pieter,


Op 7-1-2019 om 10:13 schreef Frederic Lecaille:

On 12/23/18 11:38 PM, PiBa-NL wrote:
As requested hereby the regtest send for inclusion into the git 
repository.

It is OK like that.

Note that you patch do not add reg-test/filters/common.pem which 
could be a symlink to ../ssl/common.pem.
Also note that since 8f16148Christopher's commit, we add such a line 
where possible:

    ${no-htx} option http-use-htx
We should also rename your test files to reg-test/filters/h0.*
Thank you.
Fred.


Together with these changes you have supplied me already off-list, 
i've also added a " --max-time 15" for the curl request, that should 
be sufficient for most systems to complete the 3 second testcase, and 
allows the shell command to complete without varnishtest killing it 
after a timeout and not showing any of the curl output..


One last question, currently its being added to a new folder: 
reg-test/filters/ , perhaps it should be in reg-test/compression/ ?
If you agree that needs changing i guess that can be done upon 
committing it?


I have modified your patch to move your new files to reg-test/compression.

I have also applied this to it ;) :   's/\r$//'


Note that the test fails on my FreeBSD system when using HTX when 
using '2.0-dev0-251a6b7 2019/01/08', i'm not aware it ever worked (i 
didn't test it with HTX before..).
 top  15.2 shell_out|curl: (28) Operation timed out after 15036 
milliseconds with 187718 bytes received


Ok, I will take some time to have a look at this BSD specific issue.
Note that we can easily use the CLI at the end of the script to
troubleshooting anything.


I have applied such a patch to troubleshoot your script on FreeBSD11:

$ diff -u reg-tests/compression/s0.vtc /tmp/s0.vtc
--- reg-tests/compression/s0.vtc2019-01-09 10:14:49.08228 +0100
+++ /tmp/s0.vtc 2019-01-09 13:55:09.180291504 +0100
@@ -32,7 +32,7 @@
http-request use-service lua.fileloader-http01
 } -start

-shell {
+shell -exit ${shell_status} {
 HOST=${h1_fe1_addr}
 if [ "${h1_fe1_addr}" = "::1" ] ; then
 HOST="\[::1\]"
@@ -57,3 +57,10 @@
 done

 } -run
+
+haproxy h1 -cli {
+send "show fd"
+expect ~ .*
+} -wait
+
+

to give a chance to the script to access the CLI without exiting
after having run the shell with htx enable or not as follows:

varnishtest -Dno-htx=  -Dshell_status=1
varnishtest -Dno-htx=# -Dshell_status=0


I got these show fd traces when the script fails:


 h1   15.4 CLI recv|  3 : st=0x05(R:PrA W:pra) ev=0x01(heopI) 
[lc] cnext=-3 cprev=-2 tmask=0x umask=0x0 
owner=0x802825480 iocb=0x511b70(listener_accept) l.st=RDY fe=GLOBAL
 h1   15.4 CLI recv|  4 : st=0x05(R:PrA W:pra) ev=0x01(heopI) 
[lc] cnext=-3 cprev=-2 tmask=0x umask=0x0 
owner=0x802825600 iocb=0x511b70(listener_accept) l.st=RDY fe=main-https
 h1   15.4 CLI recv|  5 : st=0x05(R:PrA W:pra) ev=0x01(heopI) 
[lc] cnext=-3 cprev=-2 tmask=0x umask=0x0 
owner=0x802825780 iocb=0x511b70(listener_accept) l.st=RDY fe=fileloader
 h1   15.4 CLI recv|  7 : st=0x05(R:PrA W:pra) ev=0x00(heopi) 
[lc] cnext=-3 cprev=0 tmask=0x umask=0x0 
owner=0x802825300 iocb=0x511b70(listener_accept) l.st=RDY fe=GLOBAL
 h1   15.4 CLI recv|  8 : st=0x05(R:PrA W:pra) ev=0x00(heopi) 
[lc] cnext=-3 cprev=0 tmask=0x1 umask=0x0 owner=0x534670 
iocb=0x534670(poller_pipe_io_handler)
 h1   15.4 CLI recv| 10 : st=0x22(R:pRa W:pRa) ev=0x01(heopI) 
[lc] cnext=-3 cprev=-2 tmask=0x1 umask=0x0 owner=0x802b55000 
iocb=0x526860(conn_fd_handler) back=0 cflg=0x80241300 fe=main-https 
mux=h1 ctx=0x80281cfc0 h1c.flg=0x0 .sub=0 .ibuf=0@0x0+0/0 
.obuf=0@0x0+0/0 h1s=0x80281d080 h1s.flg=0x10 .req.state=MSG_DONE 
.res.state=MSG_DATA .meth=GET status=200 .cs.flg=0x3000 
.cs.data=0x802bfe698
 h1   15.4 CLI recv| 11 : st=0x25(R:PrA W:pRa) ev=0x00(heopi) 
[lc] cnext=-3 cprev=-2 tmask=0x1 umask=0x0 owner=0x802b55540 
iocb=0x526860(conn_fd_handler) back=0 cflg=0x00201306 fe=GLOBAL mux=PASS 
ctx=0x80289f780
 h1   15.4 CLI recv| 13 : st=0x25(R:PrA W:pRa) ev=0x01(heopI) 
[Lc] cnext=-3 cprev=-2 tmask=0x1 umask=0x0 owner=0x802b55700 
iocb=0x526860(conn_fd_handler) back=1 cflg=0x00202306 
sv=LocalSrv/TestBack mux=h1 ctx=0x80281d200 h1c.flg=0x0 .sub=1 
.ibuf=0@0x0+0/0 .obuf=0@0x0+0/0 h1s=0x80281d500 h1s.flg=0x10 
.req.state=MSG_DONE .res.state=MSG_DATA .meth=GET status=200 
.cs.flg=0x .cs.data=0x802bfe6d8
 h1   15.4 CLI recv| 14 : st=0x25(R:PrA W:pRa) ev=0x04(heOpi) 
[lc] cnext=-3 cprev=-2 tmask=0x1 umask=0x0 owner=0x802b55a80 
iocb=0x526860(conn_fd_handler) back=0 cflg=0x80201306 fe=fileloader 
mux=h1 ctx=0x80281d680 h1c.flg=0x0 .sub=1 .ibuf=0@0x0+0/0 
.obuf=0@0x0+0/0 h1s=0x80281d740 h1s.flg=0x80 .req.state=MSG_RQBEFORE 
.res

Re: [PATCH] REGTEST: filters: add compression test


On 1/8/19 11:25 PM, PiBa-NL wrote:

Hi Frederic,


Hi Pieter,


Op 7-1-2019 om 10:13 schreef Frederic Lecaille:

On 12/23/18 11:38 PM, PiBa-NL wrote:
As requested hereby the regtest send for inclusion into the git 
repository.

It is OK like that.

Note that you patch do not add reg-test/filters/common.pem which could 
be a symlink to ../ssl/common.pem.
Also note that since 8f16148Christopher's commit, we add such a line 
where possible:

    ${no-htx} option http-use-htx
We should also rename your test files to reg-test/filters/h0.*
Thank you.
Fred.


Together with these changes you have supplied me already off-list, i've 
also added a " --max-time 15" for the curl request, that should be 
sufficient for most systems to complete the 3 second testcase, and 
allows the shell command to complete without varnishtest killing it 
after a timeout and not showing any of the curl output..


One last question, currently its being added to a new folder: 
reg-test/filters/ , perhaps it should be in reg-test/compression/ ?
If you agree that needs changing i guess that can be done upon 
committing it?


I have modified your patch to move your new files to reg-test/compression.

I have also applied this to it ;) :   's/\r$//'


Note that the test fails on my FreeBSD system when using HTX when using 
'2.0-dev0-251a6b7 2019/01/08', i'm not aware it ever worked (i didn't 
test it with HTX before..).
 top  15.2 shell_out|curl: (28) Operation timed out after 15036 
milliseconds with 187718 bytes received


Ok, I will take some time to have a look at this BSD specific issue.
Note that we can easily use the CLI at the end of the script to
troubleshooting anything.

Log attached.. Would it help to log it with the complete "filter trace 
name BEFORE / filter compression / filter trace name AFTER" ? Or are 
there other details i could try and gather?


I do not fill at ease enough on compression/filter topics to reply
to your question Pieter ;)

Nevertheless I think your test deserve to be merged.

*The patch to be merged is attached to this mail*.

Thank a lot Pieter.

Regards,
Fred.
>From a7d6b4d0c00973ab25f63491a1c860a5d14c28a9 Mon Sep 17 00:00:00 2001
From: PiBa-NL 
Date: Sun, 23 Dec 2018 21:21:51 +0100
Subject: [PATCH] REGTEST: filters: add compression test

This test checks that data transferred with compression is correctly received at different download speeds
---
 reg-tests/compression/common.pem |  1 +
 reg-tests/compression/s0.lua | 19 +
 reg-tests/compression/s0.vtc | 59 
 3 files changed, 79 insertions(+)
 create mode 12 reg-tests/compression/common.pem
 create mode 100644 reg-tests/compression/s0.lua
 create mode 100644 reg-tests/compression/s0.vtc

diff --git a/reg-tests/compression/common.pem b/reg-tests/compression/common.pem
new file mode 12
index ..a4433d56
--- /dev/null
+++ b/reg-tests/compression/common.pem
@@ -0,0 +1 @@
+../ssl/common.pem
\ No newline at end of file
diff --git a/reg-tests/compression/s0.lua b/reg-tests/compression/s0.lua
new file mode 100644
index ..2cc874b9
--- /dev/null
+++ b/reg-tests/compression/s0.lua
@@ -0,0 +1,19 @@
+
+local data = "abcdefghijklmnopqrstuvwxyz"
+local responseblob = ""
+for i = 1,1 do
+  responseblob = responseblob .. "\r\n" .. i .. data:sub(1, math.floor(i % 27))
+end
+
+http01applet = function(applet)
+  local response = responseblob
+  applet:set_status(200)
+  applet:add_header("Content-Type", "application/javascript")
+  applet:add_header("Content-Length", string.len(response)*10)
+  applet:start_response()
+  for i = 1,10 do
+applet:send(response)
+  end
+end
+
+core.register_service("fileloader-http01", "http", http01applet)
diff --git a/reg-tests/compression/s0.vtc b/reg-tests/compression/s0.vtc
new file mode 100644
index ..79e1ab56
--- /dev/null
+++ b/reg-tests/compression/s0.vtc
@@ -0,0 +1,59 @@
+# Checks that compression doesnt cause corruption..
+
+varnishtest "Compression validation"
+#REQUIRE_VERSION=1.6
+
+feature ignore_unknown_macro
+
+haproxy h1 -conf {
+global
+#	log stdout format short daemon
+	lua-load		${testdir}/s0.lua
+
+defaults
+	mode			http
+	log			global
+	${no-htx} option http-use-htx
+	option			httplog
+
+frontend main-https
+	bind			"fd@${fe1}" ssl crt ${testdir}/common.pem
+	compression algo gzip
+	compression type text/html text/plain application/json application/javascript
+	compression offload
+	use_backend TestBack  if  TRUE
+
+backend TestBack
+	server	LocalSrv ${h1_fe2_addr}:${h1_fe2_port}
+
+listen fileloader
+	mode http
+	bind "fd@${fe2}"
+	http-request use-service lua.fileloader-http01
+} -start
+
+shell {
+HOST=${h1_fe1_addr}
+if [ "${h1_fe1_addr}" = "::1" ] ; then
+HOST="\[::1\]"
+f

Re: regtests - with option http-use-htx

2019-01-08 Thread Frederic Lecaille


On 1/8/19 9:05 PM, PiBa-NL wrote:

Hi Frederic,

Op 8-1-2019 om 16:27 schreef Frederic Lecaille:

On 12/15/18 4:52 PM, PiBa-NL wrote:

Hi List, Willy,

Trying to run some existing regtests with added option: option 
http-use-htx


Using: HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15

I get the below issues sofar:

 based on /reg-tests/connection/b0.vtc
Takes 8 seconds to pass, in a slightly modified manor 1.1 > 2.0 
expectation for syslog. This surely needs a closer look?

#    top  TEST ./htx-test/connection-b0.vtc passed (8.490)

 based on /reg-tests/stick-table/b1.vtc
Difference here is the use=1 vs use=0 , maybe that is better, but 
then the 'old' expectation seems wrong, and the bug is the case 
without htx?


Note that the server s1 never responds.

Furthermore, c1 client is run with -run argument.
This means that we wait for its termination before running accessing CLI.
Then we check that there is no consistency issue with the stick-table:

if the entry has expired we get only this line:

    table: http1, type: ip, size:1024, used:0

if not we get these two lines:

    table: http1, type: ip, size:1024, used:1
    .*    use=0 ...

here used=1 means there is still an entry in the stick-table, and 
use=0 means it is not currently in use (I guess this is because the 
client has closed its connection).


I do not reproduce your issue with this script both on Linux and 
FreeBSD 11 both with or without htx.
Did you try with the 'old' development version (1.9-dev10-c11ec4a 
2018/12/15), i think in current version its already fixed see my own 
test results also below.


No. I have not tested with the previous dev versions.
I wanted to clarify the logic behind the test. I agree perhaps there is
not enough comments in this script.

 h1    0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 
gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 
http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0

 h1    0.0 CLI recv|
 h1    0.0 CLI expect failed ~ "table: http1, type: ip, 
size:1024, used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* 
gpt0=0 gpc0=0 gpc0_rate\(1\)=0 conn_rate\(1\)=1 
http_req_cnt=1 http_req_rate\(1\)=1 http_err_cnt=0 
http_err_rate\(1\)=0)\n$"


Regards,

PiBa-NL (Pieter)



I tried again today with both 2.0-dev0-251a6b7 and 1.9.0-8223050 and 
1.9-dev10-c11ec4a :


HA-Proxy version 2.0-dev0-251a6b7 2019/01/08 - https://haproxy.org/
## Without HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.146)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127)
0 tests failed, 0 tests skipped, 2 tests passed
## With HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.147)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127)
0 tests failed, 0 tests skipped, 2 tests passed


HA-Proxy version 1.9.0-8223050 2018/12/19 - https://haproxy.org/
## Without HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.150)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.128)
0 tests failed, 0 tests skipped, 2 tests passed
## With HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.148)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127)
0 tests failed, 0 tests skipped, 2 tests passed



Ok.



HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15
Copyright 2000-2018 Willy Tarreau 
## Without HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (0.146)
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc passed (0.127)
0 tests failed, 0 tests skipped, 2 tests passed
## With HTX
#    top  TEST ./PB-TEST/2018/connection-b0.vtc passed (8.646)
*    top   0.0 TEST ./PB-TEST/2018/stick-table-b1.vtc starting
 h1    0.0 CLI recv|# table: http1, type: ip, size:1024, used:1
 h1    0.0 CLI recv|0x80262a200: key=127.0.0.1 use=1 exp=0 gpt0=0 
gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 
http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0

 h1    0.0 CLI recv|
 h1    0.0 CLI expect failed ~ "table: http1, type: ip, size:1024, 
used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 
gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 
http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$"

*    top   0.0 RESETTING after ./PB-TEST/2018/stick-table-b1.vtc
**   h1    0.0 Reset and free h1 haproxy 92940
#    top  TEST ./PB-TEST/2018/stick-table-b1.vtc FAILED (0.127) exit=2
1 tests failed, 0 tests skipped, 1 tests passed

With the 'old' 1.9-dev10 version and with HTX i can still reproduce the 
"passed (8.646)" and "use=1".. But both 1.9.0 and 2.0-dev don't show 
that behavior. I have not 'bisected' further, but i don't think there is 
anything to do a.t.m. regarding this old (already fixed) issue.


Good news.

Thanks Pieter.


Regards,

PiBa-NL (Pieter)




Regards.

Fred

Re: regtests - with option http-use-htx

2019-01-08 Thread Frederic Lecaille


On 12/15/18 4:52 PM, PiBa-NL wrote:

Hi List, Willy,

Trying to run some existing regtests with added option: option http-use-htx

Using: HA-Proxy version 1.9-dev10-c11ec4a 2018/12/15

I get the below issues sofar:

 based on /reg-tests/connection/b0.vtc
Takes 8 seconds to pass, in a slightly modified manor 1.1 > 2.0 
expectation for syslog. This surely needs a closer look?

#    top  TEST ./htx-test/connection-b0.vtc passed (8.490)

 based on /reg-tests/stick-table/b1.vtc
Difference here is the use=1 vs use=0 , maybe that is better, but then 
the 'old' expectation seems wrong, and the bug is the case without htx?


Note that the server s1 never responds.

Furthermore, c1 client is run with -run argument.
This means that we wait for its termination before running accessing CLI.
Then we check that there is no consistency issue with the stick-table:

if the entry has expired we get only this line:

table: http1, type: ip, size:1024, used:0

if not we get these two lines:

table: http1, type: ip, size:1024, used:1
.*use=0 ...

here used=1 means there is still an entry in the stick-table, and use=0 
means it is not currently in use (I guess this is because the client has 
closed its connection).


I do not reproduce your issue with this script both on Linux and FreeBSD 
11 both with or without htx.




 h1    0.0 CLI recv|0x8026612c0: key=127.0.0.1 use=1 exp=0 gpt0=0 
gpc0=0 gpc0_rate(1)=0 conn_rate(1)=1 http_req_cnt=1 
http_req_rate(1)=1 http_err_cnt=0 http_err_rate(1)=0

 h1    0.0 CLI recv|
 h1    0.0 CLI expect failed ~ "table: http1, type: ip, size:1024, 
used:(0|1\n0x[0-9a-f]*: key=127\.0\.0\.1 use=0 exp=[0-9]* gpt0=0 gpc0=0 
gpc0_rate\(1\)=0 conn_rate\(1\)=1 http_req_cnt=1 
http_req_rate\(1\)=1 http_err_cnt=0 http_err_rate\(1\)=0)\n$"


Regards,

PiBa-NL (Pieter)

Re: [PATCH] REG-TEST: mailers: add new test for 'mailers' section

2019-01-08 Thread Frederic Lecaille


On 1/7/19 9:24 PM, PiBa-NL wrote:

Hi Willy,
Op 7-1-2019 om 15:25 schreef Willy Tarreau:

Hi Pieter,

On Sun, Jan 06, 2019 at 04:38:21PM +0100, PiBa-NL wrote:

The 23654 mails received for a failed server is a bit much..

I agree. I really don't know much how the mails work to be honest, as
I have never used them. I remember that we reused a part of the tcp-check
infrastructure because by then it offered a convenient way to proceed 
with

send/expect sequences. Maybe there's something excessive in the sequence
there, such as a certain status code being expected at the end while the
mail succeeds, I don't know.

Given that this apparently has always been broken,
For 1 part its always been broken (needing the short mailer timeout to 
send all expected mails), for the other part, at least until 1.8.14 it 
used to NOT send thousands of mails so that would be a regression in the 
current 1.9 version that should get fixed on a shorter term.


Indeed this script could worked with a short mailer timeout before 
af4021e6 commit. Another git bisect shows that 53216e7d introduced the 
email bombing issue.


Note that 33a09a5f refers to 53216e7d commit.

I am not sure this can help.

Fred.

Re: [RFC PATCH] couple of reg-tests

2019-01-07 Thread Frederic Lecaille


On 1/2/19 2:17 PM, Jarno Huuskonen wrote:

Hello,


Hello Jarno,

Sorry for this late reply.


I started playing with reg-tests and came up with couple of regtests.
Is there a better subdirectory for these than http-rules ? Maybe
map/b0.vtc and converter/h* ?


No, at this time it is ok.



I'm attaching the tests for comments.



reg-tests/http-rules/h3.vtc fails on my side due to a typo in the 
regex with this error:


 h10.0 CLI regexp error: 'missing opening brace after \o' (@48) 
(^0x[a-f0-9]+ example\.org https://www\.example.\org\n0x[a-f0-9]+ 
subdomain\.example\.org https://www\.subdomain\.example\.org\n$)


.\org shoulb be replaced by \.org

Could you check on your side why you did not notice this issue please?

After checking this issue we will merge your patches. Great work!


Thank you a lot.

Fred.

Re: [PATCH] REGTEST: filters: add compression test

2019-01-07 Thread Frederic Lecaille


On 12/23/18 11:38 PM, PiBa-NL wrote:

Added LUA requirement into the test..

Op 23-12-2018 om 23:05 schreef PiBa-NL:

Hi Frederic,


Hi Pieter,

Sorry for this late reply.

As requested hereby the regtest send for inclusion into the git 
repository. Without randomization and with your .diff applied. Also 
outputting expected and actual checksum if the test fails so its clear 
that that is the issue detected.


Is it okay like this? Should the blob be bigger? As you mentioned 
needing a 10MB output to reproduce the original issue on your machine?


It is OK like that.

Note that you patch do not add reg-test/filters/common.pem which could 
be a symlink to ../ssl/common.pem.


Also note that since 8f16148Christopher's commit, we add such a line 
where possible:


${no-htx} option http-use-htx

We should also rename your test files to reg-test/filters/h0.*

Thank you.


Fred.

Re: corruption of data with compression in 1.9-dev10

2018-12-18 Thread Frederic Lecaille


On 12/12/18 2:08 AM, PiBa-NL wrote:

Hi List,

Didn't have time yet to bisect when it went wrong. But attached testfile 
produces the following output after 3 curl requests at different speeds, 
this seems to trigger a problem as the hash of the downloaded content is 
nolonger the same as it should be, (in my actual environment its a 2MB 
javascript file that comes from a iis server behind haproxy.). Took 
already a few hours more than desired to come up with a seemingly 
reliable reproduction.
1.9-dev10 is the first one i put on my production environment as i think 
release is imminent so it 'should' be pretty stable ;), (yes i know..i 
shouldn't assume..) before it was using 1.8.14.. So was quick to revert 
to that 1.8 again :).


Hello Pieter,

I think your scripts would deserve to be used in haproxy sources as reg 
tests.


Why not sending them to the ML?

Find attached to this mail a patch to make it work both on Linux and 
Freebsd systems.


If you decide to send us, you would have to modify the LUA code so that 
the HTTP service would not produce pseudo-random HTTP contents (bote 
that I had to modify the MD5 checksum to make it work on Linux).


Regards,

Fred.

diff --git a/reg-tests/filters/b5.vtc b/reg-tests/filters/b5.vtc
index 0cb62633..81567210 100644
--- a/reg-tests/filters/b5.vtc
+++ b/reg-tests/filters/b5.vtc
@@ -34,40 +34,16 @@ shell {
 if [ "${h1_fe1_addr}" = "::1" ] ; then
 HOST="\[::1\]"
 fi
-curl --compressed -k "https://$HOST:${h1_fe1_port}; -o 
${tmpdir}/outputfile1.bin
-curl --compressed -k "https://$HOST:${h1_fe1_port}; -o 
${tmpdir}/outputfile3.bin --limit-rate 300K
-curl --compressed -k "https://$HOST:${h1_fe1_port}; -o 
${tmpdir}/outputfile2.bin --limit-rate 500K
-} -run
 
-shell {
-md5sum=$(md5 -q ${tmpdir}/outputfile1.bin)
-if [ "$md5sum" =  "f0d51d274ebc7696237efec272a38c41" ]
-then
-  echo "File1 all OK"
-else
-  echo "File1 not OK $md5sum "
-  testfailed=1
-fi
+md5=$(which md5 || which md5sum)
 
-md5sum=$(md5 -q ${tmpdir}/outputfile2.bin)
-if [ "$md5sum" =  "f0d51d274ebc7696237efec272a38c41" ]
-then
-  echo "File2 all OK"
-else
-  echo "File2 not OK $md5sum "
-  testfailed=1
+if [ -z $md5 ] ; then
+echo "MD5 checksum utility not found"
+exit 1
 fi
 
-md5sum=$(md5 -q ${tmpdir}/outputfile3.bin)
-if [ "$md5sum" =  "f0d51d274ebc7696237efec272a38c41" ]
-then
-  echo "File3 all OK"
-else
-  echo "File3 not OK $md5sum "
-  testfailed=1
-fi
-
-if [ -n "$testfailed" ]; then
-  exit 1
-fi
-} -run
\ No newline at end of file
+for opt in "" "--limit-rate 300K" "--limit-rate 500K" ; do
+checksum=$(curl --compressed -k "https://$HOST:${h1_fe1_port}; $opt | 
$md5 | cut -d ' ' -f1)
+if [ "$checksum" != "0a55287fd57c5e4d19f48a9e33e53b05" ] ; then exit 
1; fi
+done
+} -run

[PATCH] REGTEST: level 1 health-check test 2.

2018-12-12 Thread Frederic Lecaille


Here is a new reg test for the health-check.

Sounds similar to h1.vtc but is more intensive with client 
connections to verify there is no connection consumption by the health

checks.

Also checks that only servers with "check" option are "health-check'ed".

Fred.
From f4a26125601cadce73535925c24f024058830b55 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Wed, 12 Dec 2018 10:51:14 +0100
Subject: [PATCH] REGTEST: level 1 health-check test 2.

With this test we check that the health-checks do not consume any connection on
the backend side.
---
 reg-tests/checks/h2.vtc | 677 
 1 file changed, 677 insertions(+)
 create mode 100644 reg-tests/checks/h2.vtc

diff --git a/reg-tests/checks/h2.vtc b/reg-tests/checks/h2.vtc
new file mode 100644
index ..7246
--- /dev/null
+++ b/reg-tests/checks/h2.vtc
@@ -0,0 +1,677 @@
+varnishtest "Health-checks"
+feature ignore_unknown_macro
+
+#REQUIRE_VERSION=1.8
+
+# This script start 40 servers named s0 up to s39.
+# For 0 <= i <= 19:
+#   - s(i) and s(i+1) belong to backend be(2*i+1),
+#   - fe(2*i+1) backend is configured to used be(2*i+1) backend.
+#   - only s(2*i+1) servers have health-checks enabled,
+#   - we start 20 clients named s(2*i+1) which connect to fe(2*i+1) frontend,
+#   - so that to ensure that health-checks do not consume any connection
+# (any varnishtest server without -repeat  with n > 1 accepts
+# only one connection).
+
+# Note that the first syslog message received is: "Proxy  started."
+syslog S1 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be1 started."
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be1/srv1 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+} -start
+
+syslog S3 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be3 started."
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be3/srv3 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+} -start
+
+syslog S5 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be5 started."
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be5/srv5 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+} -start
+
+syslog S7 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be7 started."
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be7/srv7 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+} -start
+
+syslog S9 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be9 started."
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be9/srv9 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+} -start
+
+syslog S11 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be11 started."
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be11/srv11 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+} -start
+
+syslog S13 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be13 started."
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be13/srv13 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+} -start
+
+syslog S15 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be15 started."
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be15/srv15 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+} -start
+
+syslog S17 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be17 started."
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be17/srv17 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+} -start
+
+syslog S19 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be19 started."
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be19/srv19 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+} -start
+
+syslog S21 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be21 started."
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be21/srv21 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+} -start
+
+syslog S23 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Proxy be23 started."
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be23/srv23 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+} -start
+
+syslog S25

Re: [PATCH] REGTEST: Add a first test for health-checks.


On 12/11/18 7:18 PM, Frederic Lecaille wrote:

On 12/11/18 7:11 PM, Frederic Lecaille wrote:

On 12/11/18 11:46 AM, Frederic Lecaille wrote:

On 12/11/18 11:29 AM, Frederic Lecaille wrote:

On 12/11/18 11:13 AM, Frederic Lecaille wrote:

Hi ML,

Here is a first reg test for the health-checks. I hope it is as most
deterministic as possible.

At this time, I did not manage to make it fail (takes ~130ms on my 
PC).


Fred.


Well, I have not checked the haproxy version required for this test.
I will send a new patch to fix this issue.




Seems to require 1.8 because of the "srvrecord" server state field.

Here is a new patch.

Fred.


In fact this script may fail.
I will send a new patch soon.

Fred.



Here is a better version.


Found other issues again.

This is the last one.
>From 65bbbd50d512d6609a060c3fa1c2e759bd03f718 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Mon, 10 Dec 2018 17:32:15 +0100
Subject: [PATCH] REGTEST: Add a first test for health-checks.

---
 reg-tests/checks/h0.vtc | 207 
 1 file changed, 207 insertions(+)
 create mode 100644 reg-tests/checks/h0.vtc

diff --git a/reg-tests/checks/h0.vtc b/reg-tests/checks/h0.vtc
new file mode 100644
index ..d92d11c6
--- /dev/null
+++ b/reg-tests/checks/h0.vtc
@@ -0,0 +1,207 @@
+varnishtest "Health-check test"
+feature ignore_unknown_macro
+
+#REQUIRE_VERSION=1.8
+
+# This script test health-checks for four backends with one server by backend.
+# A syslog server is attached to each backend to check the syslog messages
+# in the righ order.
+
+# First, we check a health-check has passed for all the servers thanks to the syslog
+# messages. Then each server is disabled. The health-check status are checked.
+# Then each server is re-enabled. Finally health-check status
+# verifications for each server terminate the execution of this script.
+
+# Note that the CLI is synchronized with the syslog servers so that
+# to be sure to receive the passed health-checks status messages before
+# disabling the servers. Same thing, when we check that the servers are down
+# before enabling the servers.
+
+# Cyclic barrier to synchonize the CLI with the syslog servers
+barrier b1 sock 5 -cyclic
+
+# These servers are there only for the health-check test.
+server s1 {
+} -start
+
+server s2 {
+} -start
+
+server s3 {
+} -start
+
+server s4 {
+} -start
+
+syslog S1 -level notice {
+recv
+expect ~ "Proxy be1 started"
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be1/srv1 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+barrier b1 sync
+recv alert
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Server be1/srv1 is going DOWN for maintenance. 0 active and 0 backup servers left. [01] sessions active, 0 requeued, 0 remaining in queue."
+recv emerg
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: backend be1 has no server available!"
+barrier b1 sync
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: (Server be1/srv1 is UP/READY \\(leaving forced maintenance\\).|Health check for server be1/srv1 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP)"
+barrier b1 sync
+} -start
+
+syslog S2 -level notice {
+recv
+expect ~ "Proxy be2 started"
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be2/srv2 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+barrier b1 sync
+recv alert
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Server be2/srv2 is going DOWN for maintenance. 0 active and 0 backup servers left. [01] sessions active, 0 requeued, 0 remaining in queue."
+recv emerg
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: backend be2 has no server available!"
+barrier b1 sync
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: (Server be2/srv2 is UP/READY \\(leaving forced maintenance\\).|Health check for server be2/srv2 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP)"
+barrier b1 sync
+} -start
+
+syslog S3 -level notice {
+recv
+expect ~ "Proxy be3 started"
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be3/srv3 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+barrier b1 sync
+recv alert
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Server be3/srv3 is going DOWN for maintenance. 0 active and 0 backup servers left. [01] sessions active, 0 requeued, 0 remaining in queue."
+recv emerg
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: backend be3 has no server available!"
+barrier b1 sync
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: (Server be3/srv3 is UP/READY \\(leaving forced maintenance\\).|Health chec

Re: [PATCH] REGTEST: Add a first test for health-checks.


On 12/11/18 7:11 PM, Frederic Lecaille wrote:

On 12/11/18 11:46 AM, Frederic Lecaille wrote:

On 12/11/18 11:29 AM, Frederic Lecaille wrote:

On 12/11/18 11:13 AM, Frederic Lecaille wrote:

Hi ML,

Here is a first reg test for the health-checks. I hope it is as most
deterministic as possible.

At this time, I did not manage to make it fail (takes ~130ms on my PC).

Fred.


Well, I have not checked the haproxy version required for this test.
I will send a new patch to fix this issue.




Seems to require 1.8 because of the "srvrecord" server state field.

Here is a new patch.

Fred.


In fact this script may fail.
I will send a new patch soon.

Fred.



Here is a better version.

Fred.
>From 818ca62fbd00be0cd7489f75e0c01ae803f54f1b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Mon, 10 Dec 2018 17:32:15 +0100
Subject: [PATCH] REGTEST: Add a first test for health-checks.

---
 reg-tests/checks/h0.vtc | 207 
 1 file changed, 207 insertions(+)
 create mode 100644 reg-tests/checks/h0.vtc

diff --git a/reg-tests/checks/h0.vtc b/reg-tests/checks/h0.vtc
new file mode 100644
index ..97c9b8d8
--- /dev/null
+++ b/reg-tests/checks/h0.vtc
@@ -0,0 +1,207 @@
+varnishtest "Health-check test"
+feature ignore_unknown_macro
+
+#REQUIRE_VERSION=1.8
+
+# This script test health-checks for four backends with one server by backend.
+# A syslog server is attached to each backend to check the syslog messages
+# in the righ order.
+
+# First, we check a health-check has passed for all the servers thanks to the syslog
+# messages. Then each server is disabled. The health-check status are checked.
+# Then each server is re-enabled. Finally health-check status
+# verifications for each server terminate the execution of this script.
+
+# Note that the CLI is synchronized with the syslog servers so that
+# to be sure to receive the passed health-checks status messages before
+# disabling the servers. Same thing, when we check that the servers are down
+# before enabling the servers.
+
+# Cyclic barrier to synchonize the CLI with the syslog servers
+barrier b1 sock 5 -cyclic
+
+# These servers are there only for the health-check test.
+server s1 {
+} -start
+
+server s2 {
+} -start
+
+server s3 {
+} -start
+
+server s4 {
+} -start
+
+syslog S1 -level notice {
+recv
+expect ~ "Proxy be1 started"
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be1/srv1 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+barrier b1 sync
+recv alert
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Server be1/srv1 is going DOWN for maintenance. 0 active and 0 backup servers left. [01] sessions active, 0 requeued, 0 remaining in queue."
+recv emerg
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: backend be1 has no server available!"
+barrier b1 sync
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: (Server be1/srv1 is UP/READY \\(leaving forced maintenance\\).|Health check for server be1/srv1 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP)"
+barrier b1 sync
+} -start
+
+syslog S2 -level notice {
+recv
+expect ~ "Proxy be2 started"
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be2/srv2 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+barrier b1 sync
+recv alert
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Server be2/srv2 is going DOWN for maintenance. 0 active and 0 backup servers left. [01] sessions active, 0 requeued, 0 remaining in queue."
+recv emerg
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: backend be2 has no server available!"
+barrier b1 sync
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: (Server be2/srv2 is UP/READY \\(leaving forced maintenance\\).|Health check for server be2/srv2 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP)"
+barrier b1 sync
+} -start
+
+syslog S3 -level notice {
+recv
+expect ~ "Proxy be3 started"
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be3/srv3 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+barrier b1 sync
+recv alert
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Server be3/srv3 is going DOWN for maintenance. 0 active and 0 backup servers left. [01] sessions active, 0 requeued, 0 remaining in queue."
+recv emerg
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: backend be3 has no server available!"
+barrier b1 sync
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: (Server be3/srv3 is UP/READY \\(leaving forced maintenance\\).|Health check for server be3/srv3 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+m

Re: [PATCH] REGTEST: Add a first test for health-checks.


On 12/11/18 11:46 AM, Frederic Lecaille wrote:

On 12/11/18 11:29 AM, Frederic Lecaille wrote:

On 12/11/18 11:13 AM, Frederic Lecaille wrote:

Hi ML,

Here is a first reg test for the health-checks. I hope it is as most
deterministic as possible.

At this time, I did not manage to make it fail (takes ~130ms on my PC).

Fred.


Well, I have not checked the haproxy version required for this test.
I will send a new patch to fix this issue.




Seems to require 1.8 because of the "srvrecord" server state field.

Here is a new patch.

Fred.


In fact this script may fail.
I will send a new patch soon.

Fred.

[PATCH] REGTEST: Reg test for "check" health-check option


Here is a new patch for a new reg test (health-check).

Fred.
From 6d1d882d19c25482d4c2ece7a9baad9452d19c3d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Tue, 11 Dec 2018 16:19:34 +0100
Subject: [PATCH] REGTEST: Reg test for "check" health-check option.

---
 reg-tests/checks/h1.vtc | 114 
 1 file changed, 114 insertions(+)
 create mode 100644 reg-tests/checks/h1.vtc

diff --git a/reg-tests/checks/h1.vtc b/reg-tests/checks/h1.vtc
new file mode 100644
index ..00a36de3
--- /dev/null
+++ b/reg-tests/checks/h1.vtc
@@ -0,0 +1,114 @@
+varnishtest "Health-checks: only for servers with 'check' set"
+feature ignore_unknown_macro
+
+# This test start 40 servers in the same backend, named srv0 up to srv39.
+# Only the odd servers have health-checks enabled.
+# The first health-checks passed tests are checked for all these servers
+# thanks to syslog messages.
+
+# Note that the first syslog message received is: "Proxy  started."
+syslog S -repeat 21 -level notice {
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: (Health check for server be1/srv([13579]|[123][13579]) succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP|Proxy be1 started.)"
+} -start
+
+server s0 {} -start
+server s1 {} -start
+server s2 {} -start
+server s3 {} -start
+server s4 {} -start
+server s5 {} -start
+server s6 {} -start
+server s7 {} -start
+server s8 {} -start
+server s9 {} -start
+server s10 {} -start
+server s11 {} -start
+server s12 {} -start
+server s13 {} -start
+server s14 {} -start
+server s15 {} -start
+server s16 {} -start
+server s17 {} -start
+server s18 {} -start
+server s19 {} -start
+server s20 {} -start
+server s21 {} -start
+server s22 {} -start
+server s23 {} -start
+server s24 {} -start
+server s25 {} -start
+server s26 {} -start
+server s27 {} -start
+server s28 {} -start
+server s29 {} -start
+server s30 {} -start
+server s31 {} -start
+server s32 {} -start
+server s33 {} -start
+server s34 {} -start
+server s35 {} -start
+server s36 {} -start
+server s37 {} -start
+server s38 {} -start
+server s39 {} -start
+
+haproxy h1 -conf {
+defaults
+timeout client 1s
+timeout server 1s
+timeout connect 1s
+default-server no-check inter 5ms downinter 1s rise 1 fall 1
+
+backend be1
+option log-health-checks
+log ${S_addr}:${S_port} daemon
+server srv0 ${s0_addr}:${s0_port}
+server srv1 ${s1_addr}:${s1_port} check
+server srv2 ${s2_addr}:${s2_port}
+server srv3 ${s3_addr}:${s3_port} check
+server srv4 ${s4_addr}:${s4_port}
+server srv5 ${s5_addr}:${s5_port} check
+server srv6 ${s6_addr}:${s6_port}
+server srv7 ${s7_addr}:${s7_port} check
+server srv8 ${s8_addr}:${s8_port}
+server srv9 ${s9_addr}:${s9_port} check
+server srv10 ${s10_addr}:${s10_port}
+server srv11 ${s11_addr}:${s11_port} check
+server srv12 ${s12_addr}:${s12_port}
+server srv13 ${s13_addr}:${s13_port} check
+server srv14 ${s14_addr}:${s14_port}
+server srv15 ${s15_addr}:${s15_port} check
+server srv16 ${s16_addr}:${s16_port}
+server srv17 ${s17_addr}:${s17_port} check
+server srv18 ${s18_addr}:${s18_port}
+server srv19 ${s19_addr}:${s19_port} check
+server srv20 ${s20_addr}:${s20_port}
+server srv21 ${s21_addr}:${s21_port} check
+server srv22 ${s22_addr}:${s22_port}
+server srv23 ${s23_addr}:${s23_port} check
+server srv24 ${s24_addr}:${s24_port}
+server srv25 ${s25_addr}:${s25_port} check
+server srv26 ${s26_addr}:${s26_port}
+server srv27 ${s27_addr}:${s27_port} check
+server srv28 ${s28_addr}:${s28_port}
+server srv29 ${s29_addr}:${s29_port} check
+server srv30 ${s30_addr}:${s30_port}
+server srv31 ${s31_addr}:${s31_port} check
+server srv32 ${s32_addr}:${s32_port}
+server srv33 ${s33_addr}:${s33_port} check
+server srv34 ${s34_addr}:${s34_port}
+server srv35 ${s35_addr}:${s35_port} check
+server srv36 ${s36_addr}:${s36_port}
+server srv37 ${s37_addr}:${s37_port} check
+server srv38 ${s38_addr}:${s38_port}
+server srv39 ${s39_addr}:${s39_port} check
+} -start
+
+syslog S -wait
+
+haproxy h1 -cli {
+send "show servers state"
+expect ~ "# be_id be_name srv_id srv_name srv_addr srv_op_state srv_admin_state srv_uweight srv_iweight srv_time_since_last_change srv_check_status srv_check_result srv_check_health srv_check_state srv_agent_state bk_f_forced_id srv_f_forced_id srv_fqdn srv_port srvrecord\n2 be1 1 srv0 ${s0_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 - ${s0_port} -\n2 be1 2 srv1 ${s1_addr} 2 0 1 1 [[:digit:]]+ 6 ([[:digit:]]+ ){3}0 0 0 - ${s1_port} -\n2 be1 3 srv2 ${s2_addr} 2 0 1 1 [[:digit:]]+ 1 0 1 0 0 0 0 - ${s2_port} -\n2 be1 4 srv3

Re: [PATCH] REGTEST: Add a first test for health-checks.


On 12/11/18 11:29 AM, Frederic Lecaille wrote:

On 12/11/18 11:13 AM, Frederic Lecaille wrote:

Hi ML,

Here is a first reg test for the health-checks. I hope it is as most
deterministic as possible.

At this time, I did not manage to make it fail (takes ~130ms on my PC).

Fred.


Well, I have not checked the haproxy version required for this test.
I will send a new patch to fix this issue.




Seems to require 1.8 because of the "srvrecord" server state field.

Here is a new patch.

Fred.
>From ada959cba44767f87179cae02db48bfc96590ee8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Mon, 10 Dec 2018 17:32:15 +0100
Subject: [PATCH] REGTEST: Add a first test for health-checks.

---
 reg-tests/checks/h0.vtc | 207 
 1 file changed, 207 insertions(+)
 create mode 100644 reg-tests/checks/h0.vtc

diff --git a/reg-tests/checks/h0.vtc b/reg-tests/checks/h0.vtc
new file mode 100644
index ..106a6d9a
--- /dev/null
+++ b/reg-tests/checks/h0.vtc
@@ -0,0 +1,207 @@
+varnishtest "Health-check test"
+feature ignore_unknown_macro
+
+#REQUIRE_VERSION=1.8
+
+# This script test health-checks for four backends with one server by backend.
+# A syslog server is attached to each backend to check the syslog messages
+# in the righ order.
+
+# First, we check a health-check has passed for all the servers thanks to the syslog
+# messages. Then each server is disabled. The health-check status are checked.
+# Then each server is re-enabled. Finally health-check status
+# verifications for each server terminate the execution of this script.
+
+# Note that the CLI is synchronized with the syslog servers so that
+# to be sure to receive the passed health-checks status messages before
+# disabling the servers. Same thing, when we check that the servers are down
+# before enabling the servers.
+
+# Cyclic barrier to synchonize the CLI with the syslog servers
+barrier b1 sock 5 -cyclic
+
+# These servers are there only for the health-check test.
+server s1 {
+} -start
+
+server s2 {
+} -start
+
+server s3 {
+} -start
+
+server s4 {
+} -start
+
+syslog S1 -level notice {
+recv
+expect ~ "Proxy be1 started"
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be1/srv1 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+barrier b1 sync
+recv alert
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Server be1/srv1 is going DOWN for maintenance. 0 active and 0 backup servers left. [01] sessions active, 0 requeued, 0 remaining in queue."
+recv emerg
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: backend be1 has no server available!"
+barrier b1 sync
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: (Server be1/srv1 is UP/READY \\(leaving forced maintenance\\).|Health check for server be1/srv1 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP)"
+barrier b1 sync
+} -start
+
+syslog S2 -level notice {
+recv
+expect ~ "Proxy be2 started"
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be2/srv2 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+barrier b1 sync
+recv alert
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Server be2/srv2 is going DOWN for maintenance. 0 active and 0 backup servers left. [01] sessions active, 0 requeued, 0 remaining in queue."
+recv emerg
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: backend be2 has no server available!"
+barrier b1 sync
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: (Server be2/srv2 is UP/READY \\(leaving forced maintenance\\).|Health check for server be2/srv2 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP)"
+barrier b1 sync
+} -start
+
+syslog S3 -level notice {
+recv
+expect ~ "Proxy be3 started"
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be3/srv3 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP"
+barrier b1 sync
+recv alert
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Server be3/srv3 is going DOWN for maintenance. 0 active and 0 backup servers left. [01] sessions active, 0 requeued, 0 remaining in queue."
+recv emerg
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: backend be3 has no server available!"
+barrier b1 sync
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: (Server be3/srv3 is UP/READY \\(leaving forced maintenance\\).|Health check for server be3/srv3 succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP)"
+barrier b1 sync
+} -start
+
+syslog S4 -level notice {
+recv
+expect ~ "Proxy be4 started"
+recv
+expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Heal

Re: [PATCH] REGTEST: Add a first test for health-checks.


On 12/11/18 11:13 AM, Frederic Lecaille wrote:

Hi ML,

Here is a first reg test for the health-checks. I hope it is as most
deterministic as possible.

At this time, I did not manage to make it fail (takes ~130ms on my PC).

Fred.


Well, I have not checked the haproxy version required for this test.
I will send a new patch to fix this issue.

[PATCH] REGTEST: Add a first test for health-checks.


Hi ML,

Here is a first reg test for the health-checks. I hope it is as most
deterministic as possible.

At this time, I did not manage to make it fail (takes ~130ms on my PC).

Fred.
varnishtest "Health-check test"
feature ignore_unknown_macro

# This script test health-checks for four backends with one server by backend.
# A syslog server is attached to each backend to check the syslog messages
# in the righ order.

# First, we check a health-check has passed for all the servers thanks to the 
syslog
# messages. Then each server is disabled. The health-check status are checked.
# Then each server is re-enabled. Finally health-check status
# verifications for each server terminate the execution of this script.

# Note that the CLI is synchronized with the syslog servers so that
# to be sure to receive the passed health-checks status messages before
# disabling the servers. Same thing, when we check that the servers are down
# before enabling the servers.

# Cyclic barrier to synchonize the CLI with the syslog servers
barrier b1 sock 5 -cyclic

# These servers are there only for the health-check test.
server s1 {
} -start

server s2 {
} -start

server s3 {
} -start

server s4 {
} -start

syslog S1 -level notice {
recv
expect ~ "Proxy be1 started"
recv
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be1/srv1 
succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 
1/1 UP"
barrier b1 sync
recv alert
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Server be1/srv1 is going DOWN for 
maintenance. 0 active and 0 backup servers left. [01] sessions active, 0 
requeued, 0 remaining in queue."
recv emerg
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: backend be1 has no server available!"
barrier b1 sync
recv
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: (Server be1/srv1 is UP/READY \\(leaving 
forced maintenance\\).|Health check for server be1/srv1 succeeded, reason: 
Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP)"
barrier b1 sync
} -start

syslog S2 -level notice {
recv
expect ~ "Proxy be2 started"
recv
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be2/srv2 
succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 
1/1 UP"
barrier b1 sync
recv alert
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Server be2/srv2 is going DOWN for 
maintenance. 0 active and 0 backup servers left. [01] sessions active, 0 
requeued, 0 remaining in queue."
recv emerg
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: backend be2 has no server available!"
barrier b1 sync
recv
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: (Server be2/srv2 is UP/READY \\(leaving 
forced maintenance\\).|Health check for server be2/srv2 succeeded, reason: 
Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP)"
barrier b1 sync
} -start

syslog S3 -level notice {
recv
expect ~ "Proxy be3 started"
recv
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be3/srv3 
succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 
1/1 UP"
barrier b1 sync
recv alert
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Server be3/srv3 is going DOWN for 
maintenance. 0 active and 0 backup servers left. [01] sessions active, 0 
requeued, 0 remaining in queue."
recv emerg
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: backend be3 has no server available!"
barrier b1 sync
recv
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: (Server be3/srv3 is UP/READY \\(leaving 
forced maintenance\\).|Health check for server be3/srv3 succeeded, reason: 
Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP)"
barrier b1 sync
} -start

syslog S4 -level notice {
recv
expect ~ "Proxy be4 started"
recv
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Health check for server be4/srv4 
succeeded, reason: Layer4 check passed, check duration: [[:digit:]]+ms, status: 
1/1 UP"
barrier b1 sync
recv alert
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: Server be4/srv4 is going DOWN for 
maintenance. 0 active and 0 backup servers left. [01] sessions active, 0 
requeued, 0 remaining in queue."
recv emerg
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: backend be4 has no server available!"
barrier b1 sync
recv
expect ~ "[^:\\[ ]\\[${h1_pid}\\]: (Server be4/srv4 is UP/READY \\(leaving 
forced maintenance\\).|Health check for server be4/srv4 succeeded, reason: 
Layer4 check passed, check duration: [[:digit:]]+ms, status: 1/1 UP)"
barrier b1 sync
} -start


haproxy h1 -conf {
defaults
timeout client  1s
timeout server  1s
timeout connect 1s
default-server check inter 5ms downinter 1s rise 1 fall 1

frontend fe1
bind "fd@${fe1}"
use_backend be1

frontend fe2
bind "fd@${fe2}"
use_backend be2

frontend fe3
bind "fd@${fe3}"
use_backend be3

frontend fe4
bind "fd@${fe4}"
use_backend be4

[PATCH] REGTEST: Move LUA reg level 4 test 4 to level 1

2018-12-07 Thread Frederic Lecaille


Hi all,

I think that Pieter level 4 LUA 4 script should be moved to level 1 (as
a feature test).

Fred.
>From ac0188df083da4e240f87c34557cbf0ab9fd589d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Fri, 7 Dec 2018 11:16:35 +0100
Subject: [PATCH] REGTEST: Move LUA reg test 4 to level 1.

This Pieter script deserves to be moved to level 1 (feature test).
---
 reg-tests/lua/{b4.lua => h2.lua} | 0
 reg-tests/lua/{b4.vtc => h2.vtc} | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename reg-tests/lua/{b4.lua => h2.lua} (100%)
 rename reg-tests/lua/{b4.vtc => h2.vtc} (100%)

diff --git a/reg-tests/lua/b4.lua b/reg-tests/lua/h2.lua
similarity index 100%
rename from reg-tests/lua/b4.lua
rename to reg-tests/lua/h2.lua
diff --git a/reg-tests/lua/b4.vtc b/reg-tests/lua/h2.vtc
similarity index 100%
rename from reg-tests/lua/b4.vtc
rename to reg-tests/lua/h2.vtc
-- 
2.11.0

Re: BUG: Lua tasks can't use client sockets after bf89ff3d

2018-11-30 Thread Frederic Lecaille


On 11/30/18 2:42 AM, PiBa-NL wrote:

Hi Frederic, Adis,


Hi Pieter,


Op 29-11-2018 om 14:53 schreef Frederic Lecaille:

Hi Adis,

On 11/29/18 10:03 AM, Adis Nezirovic wrote:

On Thu, Nov 29, 2018 at 09:03:34AM +0100, Willy Tarreau wrote:

OK thanks, I'll take a look at it once I've flushed my pending stuff on
H2+HTX :-(


Great, I had my morning coffee and visited my optometrist, so here is
a fixed test script (correctly setting Host header).

P.S.
Lua usually suffers trying to do things in tasks, I don't think this is
the first time something gets broken. Can we make reg test with Lua
script (maybe strip out LuaSocket requirement)?



Yes. There already exist LUA reg tests in reg-tests/lua directory.

Fred.

Indeed some LUA tests already exists, but it didn't check to use a 
socket from a task.


Attached a new test which does, and does indeed fail on versions since 
the mentioned commit.


Great job!

Should i make a patch out of it for inclusion in git? Or can you guys do 
that once the fix is also ready.? i think it was the preferred to get 
bugfix+regtest 'linked' then ?


We do not take care anymore of linking a VTC file with a bugfix.

I will soon modify the documentation when we will switch to a new
standalone version of varnishtest program (named vtest, see
https://github.com/vtest/VTest).

Regards.

Fred

Re: [PATCH] REGTEST/MINOR: script: add run-regtests.sh script

2018-11-30 Thread Frederic Lecaille


On 11/29/18 10:04 PM, Frederic Lecaille wrote:

On 11/29/18 5:36 AM, Willy Tarreau wrote:

Hi guys,

On Wed, Nov 28, 2018 at 11:17:22AM +0100, Frederic Lecaille wrote:

Perhaps we should "chmod +x" this script.


Good point, done here.

However I'm now seeing this when starting it :

## Starting varnishtest 
##

Testing with haproxy version: 1.8-dev0-3b0a6d-66
Assert error in start_test(), vtc_main.c line 283:
   Condition((mkdir(tmpdir, 0711)) == 0) not true.
   errno = 13 (Permission denied)
./scripts/run-regtests.sh: line 299: 21484 Aborted 
$VARNISHTEST_PROGRAM $varnishtestparams $verbose $jobcount -l -k -t 10 
$testlist
## Gathering failed results 
##

find: `/proc/tty/driver': Permission denied
find: `/proc/1/task/1/fd': Permission denied
find: `/proc/1/task/1/fdinfo': Permission denied
find: `/proc/1/task/1/ns': Permission denied
find: `/proc/1/fd': Permission denied
find: `/proc/1/map_files': Permission denied
(...)

Then I stopped it using Ctrl-C.

I'm seeing a few minor issues we must still address :

   - haproxy is started from the path, which means that on all systems
 where it's installed, it will be the one provided by the system and
 not the just built one which will be tested (as happened above),
 which is confusing. I think we shouldn't search for haproxy in the
 path but use $PWD/haproxy or ./haproxy or something like this.

   - it seems there are some issues in the way TMPDIR/TESTDIR are 
created,

 as it ended up with an empty TESTDIR. In my case, TMPDIR is not set,
 so TESTDIR was set to /tmp/varnishtest_haproxy. mkdir worked (I now
 have this directory), but a test is missing on this mkdir.

   - the way the sub-directory is created is problematic on shared
 development machines, as only the first user will own the directory
 and will thus prevent other users from creating their own overthere,
 thus it's probably preferable not to create an intermediary 
directory

 in the end.

   - in my case it's mktemp which failed :

 ++ date +%Y-%m-%d_%H-%M-%S
 + TESTRUNDATETIME=2018-11-29_05-03-43
 + TESTDIR=/tmp/varnishtest_haproxy
 + mkdir -p /tmp/varnishtest_haproxy
 ++ mktemp -d /tmp/varnishtest_haproxy/2018-11-29_05-03-43.
 mktemp: cannot make temp dir 
/tmp/varnishtest_haproxy/2018-11-29_05-03-43.: Invalid argument

 + TESTDIR=

 I haven't checked why yet, but we definitely need to test the status
 code for success as well.

   - in my opinion the script is still missing a number of quotes when 
using
 string variables, especially in the directory names. If someone 
is crazy

 enough to have TMPDIR="/tmp/Temp Dir", then he'll have some fun.

   - I'm seeing a linux-specific "rm -d" at the end, it's be better to
 replace it with rmdir.

   - there's "/usr/bin/env sh" at the top of the shell script. /bin/sh is
 the portable one, I've spent lots of time in the past editing 
scripts

 where env was forced to /usr/bin while it was placed in /bin on some
 systems, so I'm pretty certain that this one is not portable at 
all :-)


Here is a patch for haproxy (named 0001-REGTEST*) to fix these issues.

Note the other patch for varnishtest which is also required (sent to PHK).

Fred.


A remaining patch for varnishtest.

Fred.
>From bdcdde3744f26059dd2151f2c30ed2151500098e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Fri, 30 Nov 2018 07:41:13 +0100
Subject: [PATCH 2/2] Support spaces in remaining filenames.

---
 bin/varnishtest/vtc_haproxy.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/bin/varnishtest/vtc_haproxy.c b/bin/varnishtest/vtc_haproxy.c
index e361aad78..ec3006505 100644
--- a/bin/varnishtest/vtc_haproxy.c
+++ b/bin/varnishtest/vtc_haproxy.c
@@ -477,7 +477,7 @@ haproxy_new(const char *name)
 	h->cli = haproxy_cli_new(h);
 	AN(h->cli);
 
-	bprintf(buf, "rm -rf %s ; mkdir -p \"%s\"", h->workdir, h->workdir);
+	bprintf(buf, "rm -rf \"%s\" ; mkdir -p \"%s\"", h->workdir, h->workdir);
 	AZ(system(buf));
 
 	VTAILQ_INSERT_TAIL(, h, list);
@@ -498,7 +498,7 @@ haproxy_delete(struct haproxy *h)
 	vtc_logclose(h->vl);
 
 	if (!leave_temp) {
-		bprintf(buf, "rm -rf %s", h->workdir);
+		bprintf(buf, "rm -rf \"%s\"", h->workdir);
 		AZ(system(buf));
 	}
 
@@ -548,7 +548,7 @@ haproxy_start(struct haproxy *h)
 	vsb = VSB_new_auto();
 	AN(vsb);
 
-	VSB_printf(vsb, "exec %s", h->filename);
+	VSB_printf(vsb, "exec \"%s\"", h->filename);
 	if (h->opt_check_mode)
 		VSB_printf(vsb, " -c");
 	else if (h->opt_daemon)
@@ -567,7 +567,7 @@ haproxy_start(struct haproxy *h)
 		bprintf(buf, "%s/pid", h->workdir);
 		h->pid_fn = strdup(buf);
 		AN(h->pid_fn);
-		VSB_printf(vsb, " -p %s", h->pid_fn);
+		VSB_printf(vsb, " -p \"%s\"", h->pid_fn);
 	}
 
 	AZ(VSB_finish(vsb));
-- 
2.11.0

Re: [PATCH] REGTEST/MINOR: script: add run-regtests.sh script


On 11/29/18 5:36 AM, Willy Tarreau wrote:

Hi guys,

On Wed, Nov 28, 2018 at 11:17:22AM +0100, Frederic Lecaille wrote:

Perhaps we should "chmod +x" this script.


Good point, done here.

However I'm now seeing this when starting it :

## Starting varnishtest ##
Testing with haproxy version: 1.8-dev0-3b0a6d-66
Assert error in start_test(), vtc_main.c line 283:
   Condition((mkdir(tmpdir, 0711)) == 0) not true.
   errno = 13 (Permission denied)
./scripts/run-regtests.sh: line 299: 21484 Aborted 
$VARNISHTEST_PROGRAM $varnishtestparams $verbose $jobcount -l -k -t 10 $testlist
## Gathering failed results ##
find: `/proc/tty/driver': Permission denied
find: `/proc/1/task/1/fd': Permission denied
find: `/proc/1/task/1/fdinfo': Permission denied
find: `/proc/1/task/1/ns': Permission denied
find: `/proc/1/fd': Permission denied
find: `/proc/1/map_files': Permission denied
(...)

Then I stopped it using Ctrl-C.

I'm seeing a few minor issues we must still address :

   - haproxy is started from the path, which means that on all systems
 where it's installed, it will be the one provided by the system and
 not the just built one which will be tested (as happened above),
 which is confusing. I think we shouldn't search for haproxy in the
 path but use $PWD/haproxy or ./haproxy or something like this.

   - it seems there are some issues in the way TMPDIR/TESTDIR are created,
 as it ended up with an empty TESTDIR. In my case, TMPDIR is not set,
 so TESTDIR was set to /tmp/varnishtest_haproxy. mkdir worked (I now
 have this directory), but a test is missing on this mkdir.

   - the way the sub-directory is created is problematic on shared
 development machines, as only the first user will own the directory
 and will thus prevent other users from creating their own overthere,
 thus it's probably preferable not to create an intermediary directory
 in the end.

   - in my case it's mktemp which failed :

 ++ date +%Y-%m-%d_%H-%M-%S
 + TESTRUNDATETIME=2018-11-29_05-03-43
 + TESTDIR=/tmp/varnishtest_haproxy
 + mkdir -p /tmp/varnishtest_haproxy
 ++ mktemp -d /tmp/varnishtest_haproxy/2018-11-29_05-03-43.
 mktemp: cannot make temp dir 
/tmp/varnishtest_haproxy/2018-11-29_05-03-43.: Invalid argument
 + TESTDIR=

 I haven't checked why yet, but we definitely need to test the status
 code for success as well.

   - in my opinion the script is still missing a number of quotes when using
 string variables, especially in the directory names. If someone is crazy
 enough to have TMPDIR="/tmp/Temp Dir", then he'll have some fun.

   - I'm seeing a linux-specific "rm -d" at the end, it's be better to
 replace it with rmdir.

   - there's "/usr/bin/env sh" at the top of the shell script. /bin/sh is
 the portable one, I've spent lots of time in the past editing scripts
 where env was forced to /usr/bin while it was placed in /bin on some
 systems, so I'm pretty certain that this one is not portable at all :-)


Here is a patch for haproxy (named 0001-REGTEST*) to fix these issues.

Note the other patch for varnishtest which is also required (sent to PHK).

Fred.
>From 7d316b74e65be4d75802feefe3d17b37afddf04e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Thu, 29 Nov 2018 21:51:55 +0100
Subject: [PATCH] Add the support for spaces in filenames for the temporaty
 working directory.

---
 bin/varnishtest/vtc_haproxy.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bin/varnishtest/vtc_haproxy.c b/bin/varnishtest/vtc_haproxy.c
index 9d12ed671..e361aad78 100644
--- a/bin/varnishtest/vtc_haproxy.c
+++ b/bin/varnishtest/vtc_haproxy.c
@@ -477,7 +477,7 @@ haproxy_new(const char *name)
 	h->cli = haproxy_cli_new(h);
 	AN(h->cli);
 
-	bprintf(buf, "rm -rf %s ; mkdir -p %s", h->workdir, h->workdir);
+	bprintf(buf, "rm -rf %s ; mkdir -p \"%s\"", h->workdir, h->workdir);
 	AZ(system(buf));
 
 	VTAILQ_INSERT_TAIL(, h, list);
@@ -561,7 +561,7 @@ haproxy_start(struct haproxy *h)
 
 	VSB_printf(vsb, " %s", VSB_data(h->args));
 
-	VSB_printf(vsb, " -f %s ", h->cfg_fn);
+	VSB_printf(vsb, " -f \"%s\" ", h->cfg_fn);
 
 	if (h->opt_worker || h->opt_daemon) {
 		bprintf(buf, "%s/pid", h->workdir);
@@ -754,7 +754,7 @@ haproxy_write_conf(const struct haproxy *h, const char *cfg, int auto_be)
 	vsb2 = VSB_new_auto();
 	AN(vsb2);
 
-	VSB_printf(vsb, "global\n\tstats socket %s "
+	VSB_printf(vsb, "global\n\tstats socket \"%s\" "
 		   "level admin mode 600\n", h->cli_fn);
 	VSB_printf(vsb, "stats socket \"fd@${cli}\" level admin\n");
 	AZ(VSB_cat(vsb

Re: [PATCH] REGTEST/MINOR: script: add run-regtests.sh script


On 11/29/18 8:47 AM, Willy Tarreau wrote:

On Thu, Nov 29, 2018 at 05:36:35AM +0100, Willy Tarreau wrote:

However I'm well aware that it's easier to work on improvements once the
script is merged, so what I've done now is to merge it and create a
temporary "reg-tests2" target in the makefile to use it without losing
the existing one. This way everyone can work in parallel, and once the
few issues seem reliably addressed, we can definitely replace the make
target.


Unfortunately ENOCOFFEE struck me this morning and I forgot to commit
my local changes so I merged the unmodified version which replaces the
"reg-test" target.

Thus now we're condemned to quickly fix these small issues :-)


Pieter,

I am having a look at all these issues.

Regards,

Fred.

Re: BUG: Lua tasks can't use client sockets after bf89ff3d


Hi Adis,

On 11/29/18 10:03 AM, Adis Nezirovic wrote:

On Thu, Nov 29, 2018 at 09:03:34AM +0100, Willy Tarreau wrote:

OK thanks, I'll take a look at it once I've flushed my pending stuff on
H2+HTX :-(


Great, I had my morning coffee and visited my optometrist, so here is
a fixed test script (correctly setting Host header).

P.S.
Lua usually suffers trying to do things in tasks, I don't think this is
the first time something gets broken. Can we make reg test with Lua
script (maybe strip out LuaSocket requirement)?



Yes. There already exist LUA reg tests in reg-tests/lua directory.

Fred.

[PATCH] REGTEST: Fix LEVEL 4 script 0 of "connection" module.


Here is a little reg test fix.

Fred.
>From 61fd6486eee833b42a342993706b656537079242 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Thu, 29 Nov 2018 14:23:32 +0100
Subject: [PATCH] REGTEST: Fix LEVEL 4 script 0 of "connection" module.

Prevent this script from creating a UNIX socket in ${testdir} which
is the parent directory of the script. Prefer use ${tmpdir} which
is the temporary working directory for the script.
---
 reg-tests/connection/b0.vtc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/reg-tests/connection/b0.vtc b/reg-tests/connection/b0.vtc
index cbb8a7b0..50bb7494 100644
--- a/reg-tests/connection/b0.vtc
+++ b/reg-tests/connection/b0.vtc
@@ -36,14 +36,14 @@ haproxy h1 -conf {
 
 listen http
 bind-process 1
-bind unix@${testdir}/http.socket accept-proxy name ssl-offload-http
+bind unix@${tmpdir}/http.socket accept-proxy name ssl-offload-http
 option forwardfor
 
 listen ssl-offload-http
 option httplog
 bind-process 2-4
 bind "fd@${ssl}" ssl crt ${testdir}/common.pem ssl no-sslv3 alpn h2,http/1.1
-server http unix@${testdir}/http.socket send-proxy
+server http unix@${tmpdir}/http.socket send-proxy
 } -start
 
 
-- 
2.11.0

[PATCH] REGTEST: Add a basic test for the cache.

2018-11-28 Thread Frederic Lecaille


Here is a little patch for a basic test for the cache.

Fred.
>From aa301c6eef5c6797283d56b9f23266345808cd1e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20L=C3=A9caille?= 
Date: Wed, 28 Nov 2018 11:36:48 +0100
Subject: [PATCH] REGTEST: Add a basic test for the cache.

The client makes the same HTTP request four times.
The varnishtest HTTP server serves the first client request and quits.
So, the three last requests are handled by the haproxy cache.
---
 reg-tests/cache/h0.vtc | 54 ++
 1 file changed, 54 insertions(+)
 create mode 100644 reg-tests/cache/h0.vtc

diff --git a/reg-tests/cache/h0.vtc b/reg-tests/cache/h0.vtc
new file mode 100644
index ..5195816a
--- /dev/null
+++ b/reg-tests/cache/h0.vtc
@@ -0,0 +1,54 @@
+varnishtest "Basic cache test"
+
+#REQUIRE_VERSION=1.8
+
+feature ignore_unknown_macro
+
+server s1 {
+rxreq
+txresp -nolen -hdr "Transfer-Encoding: chunked"
+chunkedlen 1
+chunkedlen 1
+chunkedlen 2
+chunkedlen 3
+chunkedlen 5
+chunkedlen 8
+chunkedlen 13
+chunkedlen 21
+chunkedlen 34
+chunkedlen 55
+chunkedlen 89
+chunkedlen 144
+chunkedlen 233
+chunkedlen 0
+} -start
+
+haproxy h1 -conf {
+defaults
+mode http
+timeout connect 1s
+timeout client  1s
+timeout server  1s
+
+frontend fe
+bind "fd@${fe}"
+default_backend test
+
+backend test
+http-request cache-use my_cache
+server www ${s1_addr}:${s1_port}
+http-response cache-store my_cache
+
+cache my_cache
+	total-max-size 3
+	max-age 20
+	max-object-size 3072
+} -start
+
+
+client c1 -connect ${h1_fe_sock} {
+	txreq
+	rxresp
+	expect resp.status == 200
+	expect resp.bodylen == 609
+} -repeat 4 -run
-- 
2.11.0

Re: [PATCH] REGTEST/MINOR: script: add run-regtests.sh script

2018-11-28 Thread Frederic Lecaille


On 11/27/18 11:17 PM, PiBa-NL wrote:

Hi Frederic, Willy,

Op 27-11-2018 om 15:00 schreef Frederic Lecaille:

On 11/27/18 10:44 AM, Frederic Lecaille wrote:

On 11/27/18 9:52 AM, Willy Tarreau wrote:

Hi guys,

On Tue, Nov 27, 2018 at 09:45:25AM +0100, Frederic Lecaille wrote:

I put the script in the /reg-tests/ folder. Maybe it should have been
besides the Makefile in the / root ?


Yes I think it should be placed at the same level as the Makefile.


Well, we already have a "scripts" directory with the stuff used for
release and backport management. I think it perfectly has its place
there.

/scripts/ sounds good.


Note that the reg tests must be run from the Makefile with 
"reg-tests" target and possibly other arguments/variables.

Willy recently added REG_TEST_FILES variable.


I've changed the the script to include the LEVEL parameter almost the 
way the Makefile used it, changed behavior though so without the 
parameter it it runs all tests.


Ok.



I am sorry Pieter a remaining detail I should have mentioned before:

+  for i in $(find $TESTDIR/ -type d -name "vtc.*");
+  do
+    echo "## $(cat $i/INFO) ##"
+    echo "## test results in: $i"
+    grep --  $i/LOG
+
+    echo "## $(cat $i/INFO) ##" >> $TESTDIR/failedtests.log
+    echo "## test results in: $i" >> $TESTDIR/failedtests.log
+    grep --  $i/LOG >> $TESTDIR/failedtests.log
+    echo >> $TESTDIR/failedtests.log
+  done

may be shortened thanks to tee command like that:

 cat <<- EOF | tee $TESDIR/failedtests.log
 .
 .
 EOF

Removed some spaces for indentation which became part of the output.


To make <<- operator work (I think it is portable) we must
add TABS to align the code. And indeed the remaining spaces are taken
into an account. Let's forget that, it is ok with your modifications.



I have tested you script. For me it is OK. Good job!
Thank you a lot Pieter.


OK just let me know what to do with this, should I merge it as-is and
expect minor updates later, or do you or Pieter want to resend an
updated version ? I can adapt, let me know.


I have modified Pieter's patch for the modification mentioned above.
Seems to work ;)


Willy,

Here is a better patch which takes into an account the modification
above and yours (the script is added in "tests" directory).
I think Willy mentioned a 'scripts' directory? Changed patch to include 
that as well.


Aww yes, sorry.



You can merge it as-is.

Regards,

Fred


New path attached, which includes a LEVEL check.
And a modification of the Makefile to call the ./scripts/run-regtests.sh

Please can someone check it again before merging.?. Thanks guys :).


Perhaps we should "chmod +x" this script.

It is OK on my side.

Thank you Pieter.

Fred.

Re: [PATCH] REGTEST/MINOR: script: add run-regtests.sh script

2018-11-27 Thread Frederic Lecaille


On 11/27/18 10:44 AM, Frederic Lecaille wrote:

On 11/27/18 9:52 AM, Willy Tarreau wrote:

Hi guys,

On Tue, Nov 27, 2018 at 09:45:25AM +0100, Frederic Lecaille wrote:

I put the script in the /reg-tests/ folder. Maybe it should have been
besides the Makefile in the / root ?


Yes I think it should be placed at the same level as the Makefile.


Well, we already have a "scripts" directory with the stuff used for
release and backport management. I think it perfectly has its place
there.


I am sorry Pieter a remaining detail I should have mentioned before:

+  for i in $(find $TESTDIR/ -type d -name "vtc.*");
+  do
+    echo "## $(cat $i/INFO) ##"
+    echo "## test results in: $i"
+    grep --  $i/LOG
+
+    echo "## $(cat $i/INFO) ##" >> $TESTDIR/failedtests.log
+    echo "## test results in: $i" >> $TESTDIR/failedtests.log
+    grep --  $i/LOG >> $TESTDIR/failedtests.log
+    echo >> $TESTDIR/failedtests.log
+  done

may be shortened thanks to tee command like that:

 cat <<- EOF | tee $TESDIR/failedtests.log
 .
 .
 EOF

I have tested you script. For me it is OK. Good job!
Thank you a lot Pieter.


OK just let me know what to do with this, should I merge it as-is and
expect minor updates later, or do you or Pieter want to resend an
updated version ? I can adapt, let me know.


I have modified Pieter's patch for the modification mentioned above.
Seems to work ;)


Willy,

Here is a better patch which takes into an account the modification
above and yours (the script is added in "tests" directory).

You can merge it as-is.

Regards,

Fred
>From 4432c10a0a822619c152aa187f18b2f6478ac565 Mon Sep 17 00:00:00 2001
From: PiBa-NL 
Date: Sun, 25 Nov 2018 16:46:44 +0100
Subject: [PATCH] REGTEST/MINOR: script: add run-regtests.sh script

Some tests require a minimal haproxy version or compilation options to be
able to run successfully. This script allows to add 'requirements' to tests
to check so they will automatically be skipped if a requirement is not met.
The script supports several parameters to slightly modify its behavior
including the directories to search for tests.

Also some features are not available for certain OS's these can also
be 'excluded', this should allow for the complete set of test cases to be
run on any OS against any haproxy release without 'expected failures'.

The test .vtc files will need to be modified to include their 'requirements'
by listing including text options as shown below:
#EXCLUDE_TARGETS=dos,freebsd,windows
#REQUIRE_OPTIONS=ZLIB,OPENSSL,LUA
#REQUIRE_VERSION=0.0
#REQUIRE_VERSION_BELOW=99.9,
When excluding a OS by its TARGET, please do make a comment why the test
can not succeed on that TARGET.
---
 tests/run-regtests.sh | 300 ++
 1 file changed, 300 insertions(+)
 create mode 100644 tests/run-regtests.sh

diff --git a/tests/run-regtests.sh b/tests/run-regtests.sh
new file mode 100644
index ..1094117f
--- /dev/null
+++ b/tests/run-regtests.sh
@@ -0,0 +1,300 @@
+#!/usr/bin/env sh
+
+if [ "$1" = "--help" ]; then
+  cat << EOF
+### run-regtests.sh ###
+  Running run-regtests.sh --help shows this information about how to use it
+
+  Run without parameters to run all tests in the current folder (including subfolders)
+run-regtests.sh
+
+  Provide paths to run tests from (including subfolders):
+run-regtests.sh ./tests1 ./tests2
+
+  Parameters:
+--j , To run varnishtest with multiple jobs / threads for a faster overall result
+  run-regtests.sh ./fasttest --j 16
+
+--v, to run verbose
+  run-regtests.sh --v, disables the default varnishtest 'quiet' parameter
+
+--varnishtestparams , passes custom ARGS to varnishtest
+  run-regtests.sh --varnishtestparams "-n 10"
+
+  Including text below into a .vtc file will check for its requirements 
+  related to haproxy's target and compilation options
+# Below targets are not capable of completing this test succesfully
+#EXCLUDE_TARGET=freebsd, abns sockets are not available on freebsd
+
+#EXCLUDE_TARGETS=dos,freebsd,windows
+
+# Below option is required to complete this test succesfully
+#REQUIRE_OPTION=OPENSSL, this test needs OPENSSL compiled in.
+ 
+#REQUIRE_OPTIONS=ZLIB,OPENSSL,LUA
+
+# To define a range of versions that a test can run with:
+#REQUIRE_VERSION=0.0
+#REQUIRE_VERSION_BELOW=99.9
+
+  Configure environment variables to set the haproxy and varnishtest binaries to use
+setenv HAPROXY_PROGRAM /usr/local/sbin/haproxy
+setenv VARNISHTEST_PROGRAM /usr/local/bin/varnishtest
+EOF
+  return
+fi
+
+_startswith() {
+  _str="$1"
+  _sub="$2"
+  echo "$_str" | grep "^$_sub" >/dev/null 2>&1
+}
+
+_findtests() {
+  set -f
+  for i in $( find "$1" -name "*.vtc" );

Re: [PATCH] REGTEST/MINOR: script: add run-regtests.sh script

2018-11-27 Thread Frederic Lecaille


On 11/27/18 9:52 AM, Willy Tarreau wrote:

Hi guys,

On Tue, Nov 27, 2018 at 09:45:25AM +0100, Frederic Lecaille wrote:

I put the script in the /reg-tests/ folder. Maybe it should have been
besides the Makefile in the / root ?


Yes I think it should be placed at the same level as the Makefile.


Well, we already have a "scripts" directory with the stuff used for
release and backport management. I think it perfectly has its place
there.


I am sorry Pieter a remaining detail I should have mentioned before:

+  for i in $(find $TESTDIR/ -type d -name "vtc.*");
+  do
+echo "## $(cat $i/INFO) ##"
+echo "## test results in: $i"
+grep --  $i/LOG
+
+echo "## $(cat $i/INFO) ##" >> $TESTDIR/failedtests.log
+echo "## test results in: $i" >> $TESTDIR/failedtests.log
+grep --  $i/LOG >> $TESTDIR/failedtests.log
+echo >> $TESTDIR/failedtests.log
+  done

may be shortened thanks to tee command like that:

 cat <<- EOF | tee $TESDIR/failedtests.log
 .
 .
 EOF

I have tested you script. For me it is OK. Good job!
Thank you a lot Pieter.


OK just let me know what to do with this, should I merge it as-is and
expect minor updates later, or do you or Pieter want to resend an
updated version ? I can adapt, let me know.


I have modified Pieter's patch for the modification mentioned above.
Seems to work ;)

Fred.



>From 4432c10a0a822619c152aa187f18b2f6478ac565 Mon Sep 17 00:00:00 2001
From: PiBa-NL 
Date: Sun, 25 Nov 2018 16:46:44 +0100
Subject: [PATCH] REGTEST/MINOR: script: add run-regtests.sh script

Some tests require a minimal haproxy version or compilation options to be
able to run successfully. This script allows to add 'requirements' to tests
to check so they will automatically be skipped if a requirement is not met.
The script supports several parameters to slightly modify its behavior
including the directories to search for tests.

Also some features are not available for certain OS's these can also
be 'excluded', this should allow for the complete set of test cases to be
run on any OS against any haproxy release without 'expected failures'.

The test .vtc files will need to be modified to include their 'requirements'
by listing including text options as shown below:
#EXCLUDE_TARGETS=dos,freebsd,windows
#REQUIRE_OPTIONS=ZLIB,OPENSSL,LUA
#REQUIRE_VERSION=0.0
#REQUIRE_VERSION_BELOW=99.9,
When excluding a OS by its TARGET, please do make a comment why the test
can not succeed on that TARGET.
---
 reg-tests/run-regtests.sh | 300 ++
 1 file changed, 300 insertions(+)
 create mode 100644 reg-tests/run-regtests.sh

diff --git a/reg-tests/run-regtests.sh b/reg-tests/run-regtests.sh
new file mode 100644
index ..1094117f
--- /dev/null
+++ b/reg-tests/run-regtests.sh
@@ -0,0 +1,300 @@
+#!/usr/bin/env sh
+
+if [ "$1" = "--help" ]; then
+  cat << EOF
+### run-regtests.sh ###
+  Running run-regtests.sh --help shows this information about how to use it
+
+  Run without parameters to run all tests in the current folder (including subfolders)
+run-regtests.sh
+
+  Provide paths to run tests from (including subfolders):
+run-regtests.sh ./tests1 ./tests2
+
+  Parameters:
+--j , To run varnishtest with multiple jobs / threads for a faster overall result
+  run-regtests.sh ./fasttest --j 16
+
+--v, to run verbose
+  run-regtests.sh --v, disables the default varnishtest 'quiet' parameter
+
+--varnishtestparams , passes custom ARGS to varnishtest
+  run-regtests.sh --varnishtestparams "-n 10"
+
+  Including text below into a .vtc file will check for its requirements 
+  related to haproxy's target and compilation options
+# Below targets are not capable of completing this test succesfully
+#EXCLUDE_TARGET=freebsd, abns sockets are not available on freebsd
+
+#EXCLUDE_TARGETS=dos,freebsd,windows
+
+# Below option is required to complete this test succesfully
+#REQUIRE_OPTION=OPENSSL, this test needs OPENSSL compiled in.
+ 
+#REQUIRE_OPTIONS=ZLIB,OPENSSL,LUA
+
+# To define a range of versions that a test can run with:
+#REQUIRE_VERSION=0.0
+#REQUIRE_VERSION_BELOW=99.9
+
+  Configure environment variables to set the haproxy and varnishtest binaries to use
+setenv HAPROXY_PROGRAM /usr/local/sbin/haproxy
+setenv VARNISHTEST_PROGRAM /usr/local/bin/varnishtest
+EOF
+  return
+fi
+
+_startswith() {
+  _str="$1"
+  _sub="$2"
+  echo "$_str" | grep "^$_sub" >/dev/null 2>&1
+}
+
+_findtests() {
+  set -f
+  for i in $( find "$1" -name "*.vtc" ); do
+skiptest=
+require_version="$(grep "#REQUIRE_VERSION=" "$i" | sed -e 's/.*=//')"
+require_version_below="$(grep "#REQUIRE_VERSION_BELOW="

Re: [PATCH] REGTEST/MINOR: script: add run-regtests.sh script

2018-11-27 Thread Frederic Lecaille


On 11/25/18 4:59 PM, PiBa-NL wrote:

Hi Frederic, Willy,


Hi Pieter,


Added the varnishtest script we have been discussing as a .patch this time.

I put the script in the /reg-tests/ folder. Maybe it should have been 
besides the Makefile in the / root ?


Yes I think it should be placed at the same level as the Makefile.

Note that the reg tests must be run from the Makefile with "reg-tests" 
target and possibly other arguments/variables.


Willy recently added REG_TEST_FILES variable.


Also i put a bit of comments into the commit.

I hope it is okay like this? If not, feel free to comment on them or 
change them as required.


I am sorry Pieter a remaining detail I should have mentioned before:

+  for i in $(find $TESTDIR/ -type d -name "vtc.*");
+  do
+echo "## $(cat $i/INFO) ##"
+echo "## test results in: $i"
+grep --  $i/LOG
+
+echo "## $(cat $i/INFO) ##" >> $TESTDIR/failedtests.log
+echo "## test results in: $i" >> $TESTDIR/failedtests.log
+grep --  $i/LOG >> $TESTDIR/failedtests.log
+echo >> $TESTDIR/failedtests.log
+  done

may be shortened thanks to tee command like that:

cat <<- EOF | tee $TESDIR/failedtests.log
.
.
EOF

I have tested you script. For me it is OK. Good job!
Thank you a lot Pieter.

Once this one is 'accepted' ill create a few patches for the existing 
.vtc files to include their requirements. (at least the more obvious 
ones..)


Regards,
PiBa-NL (Pieter)

Re: reg-test failures on FreeBSD, how to best adapt/skip some tests?

2018-11-23 Thread Frederic Lecaille


On 11/23/18 1:12 AM, PiBa-NL wrote:

Hi Frederic,


Hi Pieter,


I still have a '
' newline, with the IFS= but the \n and \012 didnt seem to work there..


Strangely on my PC with both bash and dash I do not have to change
IFS value to parse HAPROXY_VERSION, TARGET and OPTIONS with "read"
internal command.
Reading version,target and options works fine indeed without, however 
the loop over test files fails if any .vtc file has a space character in 
its filename. Or should we 'forbid' that with documentation.? Or is 
there another better workaround for that?


We will never use VTC files with spaces in their filenames.



I do not think it is a good idea to build TESTDIR like that:
   TESTRUNDATETIME="$(date '+%Y-%m-%d_%H-%M-%S')"
   TESTDIR=${TMPDIR:-/tmp}/varnishtest_haproxy/$TESTRUNDATETIME
   mkdir -p $TESTDIR
What if we run the tests several times at the same time?
Well they would have to run at the same second. Not sure if that would 
be wise to do.. But mktemp now solved that i guess :) at least for the 
directory name part..

Please have a look to mkstemp utility.
Without the 's' right? Done, combined with the rundatetime which i do 
like, so its 'readable' and unique, best of both ways i think?.


Yes.


Remaining details:
    cat $i/LOG | grep -- 
should be replaced by
    grep --  $i/LOG

I guess ill never learn do do this right the first time around ;). Fixed.
Note that you script is plenty of '\r' characters with no newline 
character at the end of file position:
Not sure what the 'correct' way would be. I think there is a CR LF 
everywhere at the moment? And the scripts hashbang tries to point to 
'sh', will this be a issue.? (acme.sh does the same, and seems to be run 
an lots of systems..) And if so what can i best do to avoid issues?


Yes there are \r\n characters in place of \n end of line character for 
each line.


You can check that with hexdump or od:

$ hexdump -c run-regtests.sh | head
000   #   !   /   u   s   r   /   b   i   n   /   e   n   v   s
010   h  \r  \n  \r  \n   i   f   [   "   $   1   "   =
020   "   -   -   h   e   l   p   "   ]   ;   t   h   e
030   n  \r  \n   c   a   t   <   <   E   O   F  \r
040  \n   #   #   #   r   u   n   -   r   e   g   t   e   s   t
050   s   .   s   h   #   #   #  \r  \n   R   u   n   n
060   i   n   g   r   u   n   -   r   e   g   t   e   s   t   s
070   .   s   h   -   -   h   e   l   p   s   h   o   w   s
080   t   h   i   s   i   n   f   o   r   m   a   t   i   o
090   n   a   b   o   u   t   h   o   w   t   o   u

There are chances you are using a text file editor on a non-Unix system?

You can remove them like that before

cat run-regtests.sh | tr -d '\r' >run-regtests.sh.ok


Also note that some shells do not like == operator (at line 3):

Used a single = now.

When I do not set both HAPROY_PROGRAM I get this output with a script
with a successful result.


Checks added to avoid this issue for both haproxy and varnishtest so 
they are checked to exist.


Next round :).


Shoulb be the last ;)

Thanks a lot Pieter.

Fred.

Re: reg-test failures on FreeBSD, how to best adapt/skip some tests?

2018-11-22 Thread Frederic Lecaille


On 11/19/18 10:08 PM, PiBa-NL wrote:

Hi Frederic, Willy,


Hi Pieter,

Thank you a lot again for this work Pieter.


Hello Pieter,


Do you intend to finalize this script? We would like to use it in 
haproxy sources.
Note that varnishtest already uses TMPDIR variable in place of /tmp if 
it is set in the environment.


Thanks again.

Fred.

Thanks for your advices and comments, to be honest i haven't looked at 
the script for several days, got distracted by other things ;). So sorry 
for late reply.


No problem. Sorry for my late reply too ;)


Just cleaned it up a bit. I guess its ready for another review.

I still have a '
' newline, with the IFS= but the \n and \012 didnt seem to work there..


Strangely on my PC with both bash and dash I do not have to change
IFS value to parse HAPROXY_VERSION, TARGET and OPTIONS with "read"
internal command.


I've tried to incorporate all suggestions. Lemme know if/what i missed :)



I do not think it is a good idea to build TESTDIR like that:

   TESTRUNDATETIME="$(date '+%Y-%m-%d_%H-%M-%S')"

   TESTDIR=${TMPDIR:-/tmp}/varnishtest_haproxy/$TESTRUNDATETIME
   mkdir -p $TESTDIR

What if we run the tests several times at the same time?
Please have a look to mkstemp utility.


Remaining details:

cat $i/LOG | grep -- 

should be replaced by

grep --  $i/LOG


Note that you script is plenty of '\r' characters with no newline 
character at the end of file position:


$ sh run-regtests.sh
: not founds.sh: 2: run-regtests.sh:
run-regtests.sh: 58: run-regtests.sh: Syntax error: word unexpected 
(expecting "do")

flecaille@fl-haproxy:~/src/haproxy
$ bash -x run-regtests.sh
+ $'\r'
run-regtests.sh: line 2: $'\r': command not found
run-regtests.sh: line 47: syntax error near unexpected token `$'{\r''
'un-regtests.sh: line 47: `_startswith() {


Also note that some shells do not like == operator (at line 3):

$ HAPROXY_PROGRAM=~/src/haproxy/haproxy 
VARNISHTEST_PROGRAM=~/src/varnish-cache-trunk/bin/varnishtest/varnishtest 
sh run-regtests.sh

run-regtests.sh: 3: [: unexpected operator


When I do no set both HAPROY_PROGRAM I get this output with a script
with a successful result:

$ sh run-regtests.sh

## Preparing to run tests ##
run-regtests.sh.ok: 177: run-regtests.sh.ok: haproxy: not found
Testing with haproxy version:
run-regtests.sh.ok: 192: [: =: unexpected operator
run-regtests.sh.ok: 196: [: =: unexpected operator
run-regtests.sh.ok: 200: [: =: unexpected operator
run-regtests.sh.ok: 204: [: =: unexpected operator
run-regtests.sh.ok: 208: [: =: unexpected operator
run-regtests.sh.ok: 212: [: =: unexpected operator
run-regtests.sh.ok: 216: [: =: unexpected operator
run-regtests.sh.ok: 220: [: =: unexpected operator
run-regtests.sh.ok: 224: [: =: unexpected operator
run-regtests.sh.ok: 228: [: =: unexpected operator
run-regtests.sh.ok: 232: [: =: unexpected operator
run-regtests.sh.ok: 236: [: =: unexpected operator
run-regtests.sh.ok: 240: [: =: unexpected operator
run-regtests.sh.ok: 244: [: =: unexpected operator
run-regtests.sh.ok: 248: [: =: unexpected operator
Target :
Options :
## Gathering tests to run ##
  Skip ./h2-keepalive-backend.vtc because exclude_targets
REASON: exclude_targets ',,' contains ''
  Skip ./urlp.regex.vtc because exclude_targets
REASON: exclude_targets ',,' contains ''
  Skip ./reg-tests/ssl/b0.vtc because exclude_targets
REASON: exclude_targets ',,' contains ''
  Skip ./reg-tests/spoe/b0.vtc because exclude_targets
REASON: exclude_targets ',,' contains ''
  Skip ./reg-tests/log/b0.vtc because exclude_targets
REASON: exclude_targets ',,' contains ''
  Skip ./reg-tests/stick-table/b1.vtc because exclude_targets
REASON: exclude_targets ',,' contains ''
  Skip ./reg-tests/stick-table/b0.vtc because exclude_targets
REASON: exclude_targets ',,' contains ''
  Skip ./reg-tests/server/b0.vtc because exclude_targets
REASON: exclude_targets ',,' contains ''
  Skip ./reg-tests/seamless-reload/b0.vtc because exclude_targets
REASON: exclude_targets ',,' contains ''
  Skip ./reg-tests/connection/b0.vtc because exclude_targets
REASON: exclude_targets ',,' contains ''
  Skip ./reg-tests/lua/b1.vtc because exclude_targets
REASON: exclude_targets ',,' contains ''
  Skip ./reg-tests/lua/b3.vtc because exclude_targets
REASON: exclude_targets ',,' contains ''

$ echo $?
0



Regards.

Re: varnishtest with H2>HTX>H1(keep-alive)


On 11/19/18 8:10 PM, PiBa-NL wrote:

Hi Willy,

Op 19-11-2018 om 4:37 schreef Willy Tarreau:

Hi Pieter,

On Mon, Nov 19, 2018 at 01:07:44AM +0100, PiBa-NL wrote:

Hi List,

I'm trying (and failing?) to write a H2>HTX>H1(keepalive) test.

Using haproxy 1.9-dev6-05b9b64.

Test vtc attached, i added the 'option http-use-htx' to the fe4
frontend/backend.
Is there anything else that should be changed?

For HTX, you need dev7.
Ah crap, i 'thought' i took the latest commit from the online branch. 
And stopped looking properly.  I must have been a few minutes to soon or 
something, after i read the dev7 mail.. (and i should have checked i did 
actually compile the expected version..) (which i totally didn't do in 
the excitement about htx and the late time..)


Or is my way of making the H2 request incorrect? Though the 3 tests 
before

it 'seem' to work alright.

I've never tested varnishtest on h2 yet, I don't know precisely how
it's supposed to be configured, nor what minimum version is required
for this. From an haproxy perspective, your config looks OK.

By the way, in my opinion you should remove "option http-keep-alive"
since it's the default
That was a remnant of a previous try to get keep-alive with h2 which 
then wasn't supposed to work with dev5 yet.

, and I think the config would be more readable
by replacing the "frontend"+"backend" couples with a single "listen"
for each.
Okay true, listen sections would make the config more readable :) . I'm 
just used to make a frontend+backend for almost 'everything'.. (Usually 
i have multiple backends behind one frontend anyhow..)  And also i 
'think' it shows more clearly in the logging output if it did or didn't 
get passed from frontend to the backend, but maybe thats just my 
imagination.


Below the output i get, with a unexpected '500' status, and with a 
IC-- on

the logline... It also seems it never contacted the s4 server.

Indeed, it faced an internal while trying to make the connection.
What I think happened is that H2 decoded the request (and logged it),
but the upper layer stream failed to do anything from it since it's
configured with HTX and HTX is not supported in your version. Please
note that even with dev7 you don't have H2 over HTX yet. You
definitely need to update to dev7 to eliminate a number of candidate
bugs.


Without the htx option it does make 1 request to the s4, and the second
expected request tries to make a second connection. (the 'old' way..)

Without the latest changes from dev7 it's expecetd since by default,
server-side keep-alive is lost when H2 is used on the frontend (the
connection used to be tied to the stream, so since you have a distinct
stream for each request, you used to lose the connection). In dev7 the
server-side idle connection moved to the session which is attached to
the front connection so the keep-alive will still work.

Okay new try with "1.9-dev7-1611965".

Hoping this helps,
Willy


However that still doesn't work yet (as also already seen by Frederic):

**   c4    0.2 === txreq -req GET -url /3
***  c4    0.2 tx: stream: 1, type: HEADERS (1), flags: 0x05, size: 37
**   c4    0.2 === rxresp
***  h1    0.2 debug|0007:fe4.accept(000e)=0010 from [::1:13402] 
ALPN=

 h1    0.2 STDOUT poll 0x11
***  c4    0.2 HTTP2 rx EOF (fd:6 read: No error: 0)
 c4    0.2 could not get frame header
**   c4    0.2 Ending stream 1
***  c4    0.2 closing fd 6
**   c4    0.2 Ending
*    top   0.2 RESETTING after ./PB-TEST/h2-keepalive-backend.vtc
**   h1    0.2 Reset and free h1 haproxy 31909
**   h1    0.2 Wait
**   h1    0.2 Stop HAproxy pid=31909
**   h1    0.2 WAIT4 pid=31909 status=0x008b (user 0.013928 sys 0.00)
*    h1    0.2 Expected exit: 0x0 signal: 0 core: 0
 h1    0.2 Bad exit status: 0x008b exit 0x0 signal 11 core 128
*    top   0.2 failure during reset
#    top  TEST ./PB-TEST/h2-keepalive-backend.vtc FAILED (0.169) exit=2


Note that, on my side this crash is always reproducible if we use only 
c4 and s4 (after removing all the other c[1-3] and s[1-3] clients and 
servers).


Regards,

Fred

Re: varnishtest with H2>HTX>H1(keep-alive)


On 11/19/18 1:07 AM, PiBa-NL wrote:

Hi List,


Hi Pieter,

Christopher is CC'ed.

As your mail is about reg-testing I took a look at it.


I'm trying (and failing?) to write a H2>HTX>H1(keepalive) test.

Using haproxy 1.9-dev6-05b9b64.

Test vtc attached, i added the 'option http-use-htx' to the fe4 
frontend/backend.

Is there anything else that should be changed?
Or is my way of making the H2 request incorrect? Though the 3 tests 
before it 'seem' to work alright.


Below the output i get, with a unexpected '500' status, and with a IC-- 
on the logline... It also seems it never contacted the s4 server.
Without the htx option it does make 1 request to the s4, and the second 
expected request tries to make a second connection. (the 'old' way..)


On my side I have the same issue but with random crashes:

$ gdb ./haproxy /tmp/vtc.*/h1/core
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./haproxy...done.
[New LWP 29017]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/home/flecaille/src/haproxy/haproxy -d -f 
/tmp/vtc.28995.4486bcf4/h1/cfg'.

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x556503742260 in htx_get_blk_type (blk=0x556c9a399c7c)
at include/proto/htx.h:89
89  return (blk->info >> 28);
(gdb) bt
#0  0x556503742260 in htx_get_blk_type (blk=0x556c9a399c7c)
at include/proto/htx.h:89
#1  0x55650374234b in htx_get_tail_type (htx=0x556503c2ce10)
at include/proto/htx.h:191
#2  0x556503743a31 in htx_wait_for_request (s=0x556503c26c10, 
req=0x556503c26c20,

an_bit=4) at src/proto_htx.c:119
#3  0x55650371af00 in http_wait_for_request (s=0x556503c26c10,
req=0x556503c26c20, an_bit=4) at src/proto_http.c:880
#4  0x55650375a50e in process_stream (t=0x556503c28c00, 
context=0x556503c26c10,

state=257) at src/stream.c:1974
#5  0x5565038612f9 in process_runnable_tasks () at src/task.c:421
#6  0x5565037ac272 in run_poll_loop () at src/haproxy.c:2610
#7  0x5565037ac625 in run_thread_poll_loop (data=0x556503c1f400)
at src/haproxy.c:2675
#8  0x5565037adce7 in main (argc=4, argv=0x7ffdc2362e58) at 
src/haproxy.c:3287

(gdb) p blk
$1 = (const struct htx_blk *) 0x556c9a399c7c
(gdb) p blk->info
Cannot access memory at address 0x556c9a399c80



$ ./haproxy -vv
HA-Proxy version 1.9-dev7-161196-8 2018/11/19
Copyright 2000-2018 Willy Tarreau 

Build options :
  TARGET  = linux2628
  CPU = generic
  CC  = gcc
  CFLAGS  = -g -fno-strict-aliasing -Wdeclaration-after-statement 
-fwrapv -Wno-unused-label -Wno-sign-compare -Wno-unused-parameter 
-Wno-old-style-declaration -Wno-ignored-qualifiers -Wno-clobbered 
-Wno-missing-field-initializers -Wtype-limits -Wshift-negative-value 
-Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference

  OPTIONS = USE_ZLIB=1 USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1

Default settings :
  maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200

Built with OpenSSL version : OpenSSL 1.1.0f  25 May 2017
Running on OpenSSL version : OpenSSL 1.1.0f  25 May 2017
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2
Built with Lua version : Lua 5.3.3
Built with transparent proxy support using: IP_TRANSPARENT 
IPV6_TRANSPARENT IP_FREEBIND

Built with zlib version : 1.2.8
Running on zlib version : 1.2.8
Compression algorithms supported : identity("identity"), 
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")

Built with PCRE version : 8.39 2016-06-14
Running on PCRE version : 8.39 2016-06-14
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Encrypted password support via crypt(3): yes
Built with multi-threading support.

Available polling systems :
  epoll : pref=300,  test result OK
   poll : pref=200,  test result OK
 select : pref=150,  test result OK
Total: 3 (3 usable), will use epoll.

Available multiplexer protocols :
(protocols markes as  cannot be specified using 'proto' keyword)
  h2 : mode=HTTP   side=FE
: mode=NONE   side=FE|BE
: mode=TCP|HTTP   side=FE|BE

Available filters :
[SPOE] spoe
[COMP] compression
[TRACE] trace

Re: reg-test failures on FreeBSD, how to best adapt/skip some tests?


On 11/8/18 6:11 AM, Willy Tarreau wrote:

Hi guys,

On Wed, Nov 07, 2018 at 09:37:14AM +0100, Frederic Lecaille wrote:

New 'version' of the script attached.
It now supports a set of parameters to modify its behavior a little. And
also checking for a 'version requirement'. So a H2 test doesn't have to
fail on 1.7.


Very good work.


I missed this message last week (I'm not often on the list these days
I confess), but this tool is awesome!


Should i 'ask' to delete old test result.? Or would there be a other
better way to keep previous results separated from the current run?


No.

Rename the old vtc files like that before running the tests:

bname=$(basename $i)
mv /tmp/$bname /tmp/old.$bname

with $i in $(find /tmp/ -type d -name "vtc.*")

or something like that.


It would be nice to support TMPDIR so that we can force it in a script
instead of /tmp. What I *think* could be done by default would be to
delete the old.vtc.* files there before running the tests so that we
always keep only the last results by default. I found hundreds of vtc
directories in /tmp on my laptop and that can become problematic, even
worse on shared development machines.


please *add -type d* to the find command to list the temporary varnishtest
directories.


Well, then add -maxdepth 1 or 2 because you certainly don't want to run
find into my /tmp which contains complete distros to chroot into!


And we should only keep temporaries directory of tests which have failed
with -l varnishtest option currently enabled option. They are all the
/tmp/vtc.* directories found after having run the tests.


Interesting.


So the script should list the remaining temporary directories after having
run the tests. There is no need to parse the log file of this directories.


Then I'd like to see a small change, which would be that :

   1) we rely on a user-provided base directory instead of /tmp, such as
  ${TMPDIR:-/tmp} since TMPDIR is very commonly defined ;


Pieter,

Note that varnishtest already uses TMPDIR variable in place of /tmp if 
it is set in the environment.


Regards,

Fred

Re: reg-test failures on FreeBSD, how to best adapt/skip some tests?