Re: Makefile, environment variables and REGTESTS_TYPES
Hi William,
On Fri, Jan 29, 2021 at 02:44:27PM +0100, William Lallemand wrote:
> Hello List,
>
> According to `make reg-tests-help` the REGTESTS_TYPES parameter must be
> configured as an environment variable and not a make argument.
>
> However since patch 3bad3d5 ("BUILD: Makefile: exclude broken tests by
> default"), it does not work anymore with an environment variable.
>
> Looking at the several CI files we have, it is used as a make
> argument everywhere.
I must confess I didn't even know it was expected to be used as an
environment variable and have always used it as a make argument, given
that these *are* exported as argument variables anyway. Here's what I'm
using for the make-reg-test-all script for example:
make reg-tests VTEST_PROGRAM=/usr/local/bin/vtest
REGTESTS_TYPES=default,bug,devel,slow -- --j 8 "$@" || exit 1
> I'm going to update the `make reg-tests-help` command with the correct
> syntax if there isn't any complain.
OK.
> We could fix the issue by using "?=" when setting the default value, but
> it would make it the only variable that use "?=" in the Makefile and I'm
> not sure we want to proceed this way.
No please avoid this, I find the mixing of arguments and environment
really confusing to use. The only valid use of "?=" is when you want
to support pre-setting a variable that will be completed later, but
this usually remains as it doesn't allow you to remove options, and
in general it's really bad as you get different behaviors for
$ VAR=xxx make
and:
$ make VAR=xxx
I think the reg-test users are a small enough group that any required
change can be quickly adopted if needed anyway, without having to take
too much care about backwards compatibility, as long as it remains
convenient to use.
Thanks,
Willy
Re: parsing reload cmd output from master cli
On Wed, Feb 03, 2021 at 06:32:33PM -0300, Joao Morais wrote:
>
> Hello William, here[1] is some context. I implemented a parsing of the reload
> command sent to the master cli, leave it running for a while and got an index
> out of bounds (in my code) this week.
>
> I'm using this lay out to parse the reload output:
>
> // 1 3 4 6
>8 8
> //
> 0...|...6...|...2...|...8...|...4...|...0...|...8
> //
> // #
>
> // 1 master 0 2
> 0d00h01m28s 2.2.3-0e58a34
> // # workers
> // 3 worker 1 0
> 0d00h00m00s 2.2.3-0e58a34
> // # old workers
> // 2 worker [was: 1]1
> 0d00h00m28s 2.2.3-0e58a34
> // # programs
> //
>
> Apparently I found a line that: starting char isn't '#', have 32 chars or
> more, have less than 48 chars. Is that even possible?
I had a quick look at the code producing this output and it writes
full lines at once, but the second one is a string which is mostly a
constant ("worker", "master"), or taken from a structure for old
programs. So I'm seeing two possibilities:
- either your parser received an incomplete line due to network buffering
and decided to parse it before getting the trailing "\n"; this is a
pretty common issue in line-oriented parsers ported to consume data
from other processes ;
- or the process memory was corrupted so that an old program's "child->id"
contained some crap and a "\n", which would have resulted in printing
the PID, this crappy string, and the rest of the line on a second separate
line.
The last point seems pretty possible given that your outdated version is
affected by 123 known bugs, 2 of which could cause memory corruption.
> How would you expand the lay out above, so I can improve my parser and my
> tests? Thanks!
Please read the chunk_appendf() statements in cli_io_handler_show_proc(),
they're pretty explicit and you'll get the exact output format for various
types of dumps. But that's basically what's documented above, it's just
that it may help you to figure some constants there (or that some fields
are unsigned for example).
Cheers,
Willy
Re: A faster way to lookup 5k hosts+paths
Hi Joao,
On Tue, Feb 02, 2021 at 09:03:06PM -0300, Joao Morais wrote:
>
> Hello list, I've about 5000 hostnames + path that should be mapped to 3000
> backends or so. I'm using map converters and the lay out is something like
> this:
>
> /dir/file.map
> d1.tld/path/sub back1
> d1.tld/path back2
> d2.tld/path/sub/other back3
> d2.tld/path/sub back4
> d2.tld/path back5
> d3.tld/path/sub back6
> d3.tld/path back7
>
> And frontend looks like this:
>
> http-request set-var(req.backend) base,map_beg(/dir/file.map)
> use_backend %[var(req.backend)] if { var(req.backend) -m found }
>
> The problem here is that the map has about 5k lines and the search isn't
> indexed. I could eg split this map into smaller ones and create an index of
> maps stored in another map, but cannot use the result because the file name
> param in the converter cannot be dynamic. Any other idea to help haproxy find
> the backend in a faster way?
Not sure why you're saying it's not indexed. It uses map_beg so it will
use a prefix tree for the lookup, it should be pretty fast.
By the way, you could simplify your rules this way:
use_backend base,map_beg(/dir/file.map)
Indeed, a use_backend rule which doesn't find the backend will do nothing
and continue to next rules.
Willy
Re: [PATCH v2 0/5] fix check port/addr consistency
Le 03/02/2021 à 12:19, William Dauchy a écrit : On Wed, Feb 3, 2021 at 9:59 AM Christopher Faulet wrote: At first glance, I'm just a bit annoyed with the patch 5. In the documentation, it is stated that "addr" option will be used for agent-check too. And there is no info about interactions between "addr" and "agent-addr" options when both are configured. For me, for an agent-check, the "agent-addr" option must be used in priority, regardless the options order. If not defined, the "addr" option must be used, if defined. And at the end, we use the server address by default if none is specified. ok I missed that part. it is a bit sad honestly, it makes things less explicit. There is another problem with "port" and "agent-port" options. It is mentioned in the documentation that "agent-port" is required to perform agent-checks. And "port" option is not used for agent-check. It is not really consistent. I propose to deal with port/agent-port options in the same way than addr/agent-addr ones. And we keep the test to be sure to have a dedicated port for the agent-check to not use the server's one. This way, we keep backward compatibility and improve consistency. Thus, if you agree with these changes, I guess we should keep SRV_F_AGENTADDR flag and add SRV_F_AGENTPORT. ok I will come back with a v3. I honestly don't like to have port/addr used for agent, as stated previously because it is creating some non explicit things. But indeed as we need to keep backward compat, I will fix that. About the CLI. I agree, the "check-addr" parameter on the "set server" command must be added. And the "agent-port" parameter must bee added too. For me, it is a consistency matter. But I understand it is also mandatory for dynamic environments. thanks, let me come back with a v3, so we can move forward for the next improvements. For the record, the series was finally fixed and pushed. Thanks William ! -- Christopher Faulet
Re: HAproxy soft reload timeout?
Hello Dominik, you are looking for hard-stop-after: http://cbonte.github.io/haproxy-dconv/2.2/configuration.html#hard-stop-after Regards, Lukas On Thu, 4 Feb 2021 at 11:40, Froehlich, Dominik wrote: > > Hi, > > > > I am currently experimenting with the HAproxy soft reload functionality (USR2 > to HAproxy master process). > > From what I understood, a new worker is started and takes over the listening > sockets while the established connections remain on the previous worker until > they are finished. > > The worker then terminates itself once all work is done. > > > > I’ve noticed there are some quite long-lived connections on my system (e.g. > websockets or tcp-keepalive connections from slow servers). So when I am > doing the reload, the previous instance > > of HAproxy basically lives as long as the last connection is still going. > Which potentially could go on forever. > > > > So when I keep reloading HAproxy because the config has changed, I could end > up with dozens, even hundreds of HAproxy instances running with old > connections. > > > > My question: Is there a way to tell the old haproxy instances how much time > they have to get done with their work and leave? > > I know it’s a tradeoff. I want my users to not be disrupted in their > connections but I also need to protect the ingress machines from overloading. > > > > Any best practices here? > > > > Cheers, > > D
Re: HAproxy soft reload timeout?
Dominik, Am 04.02.21 um 11:40 schrieb Froehlich, Dominik: > My question: Is there a way to tell the old haproxy instances how much time > they have to get done with their work and leave? Yes: https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#mworker-max-reloads https://cbonte.github.io/haproxy-dconv/2.2/configuration.html#hard-stop-after Best regards Tim Düsterhus
HAproxy soft reload timeout?
Hi, I am currently experimenting with the HAproxy soft reload functionality (USR2 to HAproxy master process). From what I understood, a new worker is started and takes over the listening sockets while the established connections remain on the previous worker until they are finished. The worker then terminates itself once all work is done. I’ve noticed there are some quite long-lived connections on my system (e.g. websockets or tcp-keepalive connections from slow servers). So when I am doing the reload, the previous instance of HAproxy basically lives as long as the last connection is still going. Which potentially could go on forever. So when I keep reloading HAproxy because the config has changed, I could end up with dozens, even hundreds of HAproxy instances running with old connections. My question: Is there a way to tell the old haproxy instances how much time they have to get done with their work and leave? I know it’s a tradeoff. I want my users to not be disrupted in their connections but I also need to protect the ingress machines from overloading. Any best practices here? Cheers, D
Re: [PATCH v3 0/5] fix check port/addr consistency
Hello Christopher, Thanks for your continuous support on this review :) On Thu, Feb 4, 2021 at 10:09 AM Christopher Faulet wrote: > Thanks William, it seems good. I've just a question (sorry :). When the server > state file is loaded, why the check port is set only if there is a DNS > resolution ? I know it was done this way before the support of check_port > parameter in the server state. But I suppose that now we support it, it should > always be set, isn't it ? yes you are totally right. > And is there any usage to add "agent-addr" in the server state file? Because > it > can also be set on the CLI. And later, same question will appear for > "check-addr" and "agent-port". the general rule is indeed, anything which can be changed through the CLI should be loaded through server states. Truth is server states becomes a nightmare to manage; I don't remember if you were in the discussions a few months ago, but we concluded we should change that long term by https://github.com/haproxy/haproxy/issues/953 So while waiting for a proper solution, we are indeed supposed to keep server states up to date. > I don't want to bother you again. So, I propose you to merge the first patch > and > to add a new one to not set the check port when the server state file is > loaded. > Then I can merge the third patch and amend the second one to move the check > port > assignment before merging it. And finally I can merge the fourth and fifth > patches. Don't worry, I can send you a v4. -- William
Re: [PATCH v3 0/5] fix check port/addr consistency
Le 03/02/2021 à 22:30, William Dauchy a écrit : Hello Christopher, Here is my last update on port/addr consistency. I addressed all the point you mentioned. I hope I did not forgot anything. I will come back with `check-addr` and `agent-port` on the cli once those patches are accepted. William Dauchy (5): BUG/MINOR: cli: fix set server addr/port coherency with health checks MEDIUM: server: adding support for check_port in server state MEDIUM: check: remove checkport checkaddr flag BUG/MINOR: check: consitent way to set agentaddr MEDIUM: check: align agentaddr and agentport behaviour Thanks William, it seems good. I've just a question (sorry :). When the server state file is loaded, why the check port is set only if there is a DNS resolution ? I know it was done this way before the support of check_port parameter in the server state. But I suppose that now we support it, it should always be set, isn't it ? And is there any usage to add "agent-addr" in the server state file? Because it can also be set on the CLI. And later, same question will appear for "check-addr" and "agent-port". I don't want to bother you again. So, I propose you to merge the first patch and to add a new one to not set the check port when the server state file is loaded. Then I can merge the third patch and amend the second one to move the check port assignment before merging it. And finally I can merge the fourth and fifth patches. -- Christopher Faulet
