Re: Feature suggestion: Check for same binding on multiple frontends

2018-03-08 Thread Lukas Tribus
Hello,


On 8 March 2018 at 06:36, Moomjian, Chad  wrote:
> Thanks for the information, Lukas. I'm confused why this is not a default 
> option though. Can you think of a time when you would ever want the exact 
> same binding in multiple places in the config?

noreuseport is not something that reads the configuration and applies
some kind of heuristics for such errors, what it does is that it makes
haproxy NOT set the SO_REUSEPORT [1] socket option.

SO_REUSEPORT is useful because it permits faster and (depending on
more factors) hitless reloads. Other than that an important use-case
is to have the kernel load-balance between different sockets on
different CPU cores for scalability reasons.



Lukas


[1] https://lwn.net/Articles/542629/



RE: Feature suggestion: Check for same binding on multiple frontends

2018-03-07 Thread Moomjian, Chad
Thanks for the information, Lukas. I'm confused why this is not a default 
option though. Can you think of a time when you would ever want the exact same 
binding in multiple places in the config?

-Original Message-
From: lu...@ltri.eu [mailto:lu...@ltri.eu] 
Sent: Wednesday, March 7, 2018 3:21 AM
To: Moomjian, Chad <cmoomj...@outmatch.com>
Cc: haproxy@formilux.org
Subject: Re: Feature suggestion: Check for same binding on multiple frontends

Hello Chad,


On 7 March 2018 at 03:34, Moomjian, Chad <cmoomj...@outmatch.com> wrote:
> Haproxy Developers,
>
>
>
> I recently modified a configuration file for haproxy, and after 
> setting it up, I noticed that about half of my requests came back with 
> a 503 error, and the other half came back with the correct elements being 
> returned.
>
>
>
> After doing troubleshooting involving a test haproxy instance and 
> changing the IP address, I realized that I had mistakenly added the 
> same IP binding, 10.x.x.11:443, in two different frontends. As a 
> result, half of my requests had no matching path (we don’t use a 
> default backend), and the other half were using responding correctly.
>
>
>
> Since I cannot think of a time when this would be desired behavior, 
> would it be possible to add a check on haproxy startup for the exact 
> same IP binding in multiple frontends of the same config file? This 
> could save me and others from possibly making this mistake in the future.

You can set noreuseport in the global section to guarantee that there is only a 
single socket bound to a port:

http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-noreuseport



Lukas



Re: Feature suggestion: Check for same binding on multiple frontends

2018-03-07 Thread Lukas Tribus
Hello Chad,


On 7 March 2018 at 03:34, Moomjian, Chad  wrote:
> Haproxy Developers,
>
>
>
> I recently modified a configuration file for haproxy, and after setting it
> up, I noticed that about half of my requests came back with a 503 error, and
> the other half came back with the correct elements being returned.
>
>
>
> After doing troubleshooting involving a test haproxy instance and changing
> the IP address, I realized that I had mistakenly added the same IP binding,
> 10.x.x.11:443, in two different frontends. As a result, half of my requests
> had no matching path (we don’t use a default backend), and the other half
> were using responding correctly.
>
>
>
> Since I cannot think of a time when this would be desired behavior, would it
> be possible to add a check on haproxy startup for the exact same IP binding
> in multiple frontends of the same config file? This could save me and others
> from possibly making this mistake in the future.

You can set noreuseport in the global section to guarantee that there
is only a single socket bound to a port:

http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#3.2-noreuseport



Lukas