Re: [PATCH] BUG/MEDIUM: dns: Correctly use weight specified in SRV record

[Baptiste]

On Thu, Oct 17, 2019 at 2:32 PM Daniel Corbett  wrote:

> Hello,
> On 10/17/19 1:47 AM, Baptiste wrote:
>
>
>
> Hi Daniel,
>
> Thanks for the patch, but I don't think it's accurate.
> What this part of the code aims to do is to "map" a DNS weight into an
> HAProxy weight.
> There is a ratio of 256 between both: DNS being in range "0-65535" and
> HAProxy in range "0-255".
> What your code does, is that it ignores any DNS weight above 256 and force
> them to 1...
>
> The only "bug" I can see here now is that a server's weight can never be
> 0. But nobody reported this as an issue yet.
>
> I'll check what question is asked into #48 and answer it.
>
>
> Ah ha!  Thanks for the explanation and my apologies for the noise.  This
> makes sense now.
>
> I have put together another patch that I will send later for the
> "resolve-opts ignore-weight" within that same issue report but wanted to
> get this one out first.
>
> Thanks for taking the time to review this Baptiste.
>
> -- Daniel
>

No problem!
I'll fix the documentation and add some comment in the code for the short
term "fix".
I'll also fix the weight at 0 as well asap.

That said, this may be a legitimate feature request: have a "custom" ratio
to apply to DNS weight to map it into HAProxy's weight. Default ratio would
be 256 and if people want to say "DNS weight 50 must match HAProxy weight
of 50" then they could set ratio to 1.
values above 256 will of course be truncated to 256.
(this idea was provided by Willy).
This is a mid term fix and if we see people need that (IE broken DNS server
implementation, etc...).

Baptiste

Re: [PATCH] BUG/MEDIUM: dns: Correctly use weight specified in SRV record

[Daniel Corbett]

Hello,

On 10/17/19 1:47 AM, Baptiste wrote:



Hi Daniel,

Thanks for the patch, but I don't think it's accurate.
What this part of the code aims to do is to "map" a DNS weight into an 
HAProxy weight.
There is a ratio of 256 between both: DNS being in range "0-65535" and 
HAProxy in range "0-255".
What your code does, is that it ignores any DNS weight above 256 and 
force them to 1...


The only "bug" I can see here now is that a server's weight can never 
be 0. But nobody reported this as an issue yet.


I'll check what question is asked into #48 and answer it.



Ah ha!  Thanks for the explanation and my apologies for the noise.  This 
makes sense now.


I have put together another patch that I will send later for the 
"resolve-opts ignore-weight" within that same issue report but wanted to 
get this one out first.



Thanks for taking the time to review this Baptiste.


-- Daniel

Contstats performances

[Gaetan Deputier]

Hello!

I'm reaching out regarding the contstats option and "small performance
drop". What is exactly the performance drop described here? Induced
latency, CPU usage?

>From what I've seen, it triggers a recount on each session every 5s, so I'd
expect a small CPU increase times the number of opened sessions but I have
not found any resources aside the source code about contstats downsides.

Thanks,

G-

Re: [PATCH] BUG/MEDIUM: dns: Correctly use weight specified in SRV record

[Luke Seelenbinder]

Hi Baptiste,

> The only "bug" I can see here now is that a server's weight can never be 0. 
> But nobody reported this as an issue yet.

I can confirm this as a bug; I've just never thought to report it. We've worked 
around it in our own setup by having separate backup and active SRV records. 
Not needing explicit backup records and simply setting weights to 0 would be 
ideal.

Best,
Luke

—
Luke Seelenbinder
Stadia Maps | Founder
stadiamaps.com

> On 17 Oct 2019, at 07:47, Baptiste  wrote:
> 
> 
> 
> On Thu, Oct 17, 2019 at 5:35 AM Daniel Corbett  > wrote:
> Hello,
> 
> 
> In #48 it was reported that when using the server-template
> 
> directive combined with an SRV record that HAProxy would
> always set the weight to "1" regardless of what the SRV record
> contains.
> 
> It was found that in an attempt to force a minimum value of "1"
> actually ended up forcing "1" in all situations.  This was due to
> an improper equation: ( x / 256 ) + 1
> 
> This patch should be backported to 1.8 and 1.9
> 
> 
> 
> Thanks,
> 
> -- Daniel
> 
> 
> 
> 
> Hi Daniel,
> 
> Thanks for the patch, but I don't think it's accurate.
> What this part of the code aims to do is to "map" a DNS weight into an 
> HAProxy weight.
> There is a ratio of 256 between both: DNS being in range "0-65535" and 
> HAProxy in range "0-255".
> What your code does, is that it ignores any DNS weight above 256 and force 
> them to 1...
> 
> The only "bug" I can see here now is that a server's weight can never be 0. 
> But nobody reported this as an issue yet.
> 
> I'll check what question is asked into #48 and answer it.
> 
> As a conclusion, please don't apply this patch.
> 
> Baptiste

Load Balancing Software Users

[Jessica John]

Hi,
I would like to know if you are interested in reaching out to Load Balancing 
Software Users.
Our data assist businesses like yours to connect potential customers through 
email, phone or direct mails.

If you are interested we can provide sample data for reference.

Thanks and Regards,
Jessica John
Marketing Manager

If you don’t want to receive any more emails from us REPLY “Unsubscribe”.

[PATCH] BUG/MINOR: server: check return value of fopen() in apply_server_state()

[Vedran Furac]

Hello,

this patch fixes the segmentation fault on start when HAProxy is configured to
load global server state file which doesn't exist. This can be considered a
regression from 1.8 which warned but continued without crashing. It needs to be
backported to 2.0.

Thanks,
Vedran
>From df3d9f27e48b29c2bf4885943a16e5a920d5471f Mon Sep 17 00:00:00 2001
From: Vedran Furac 
Date: Wed, 16 Oct 2019 14:49:38 +0200
Subject: [PATCH] BUG/MINOR: server: check return value of fopen() in
 apply_server_state()

fopen() can return NULL when state file is missing. This patch adds a
check of fopen() return value so we can skip processing in such case.
---
 src/server.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/server.c b/src/server.c
index df0dcbfe..6b740240 100644
--- a/src/server.c
+++ b/src/server.c
@@ -3595,6 +3595,8 @@ void apply_server_state(void)
 		f = fopen(globalfilepath, "r");
 		if (errno)
 			ha_warning("Can't open global server state file '%s': %s\n", globalfilepath, strerror(errno));
+		if (!f)
+			goto out_load_server_state_in_tree;
 
 		global_file_version = srv_state_get_version(f);
 		if (global_file_version == 0)
-- 
2.20.1