Re: Suggestion: better defaults for mysql-check healthcheck (post-41 enabled)

2020-04-29 Thread Willy Tarreau
On Tue, Apr 28, 2020 at 08:44:36AM +0200, Christopher Faulet wrote:
> Le 27/04/2020 à 18:15, Florent Rivoire a écrit :
> > Hello,
> > 
> > This is my first message here, so: hi everyone :)
> > And thanks to everyone involved in the Haproxy project !
> > 
> > I wanted to give an idea of a (minor) better default that should be 
> > improved:
> > => enable by default the "post-41" parameter in *mysql-check*
> > 
> > Today, it's off by default, so Haproxy is using the "very very old"
> > authentication method (before MySQL 4.1) to do the health-checks.
> > But since MySQL 4.1 is now *16* years old (stable in 2004), we are
> > fairly sure that all new installations of Haproxy will certainly be
> > used with a "recent-enough" (>= 4.1) mysql version that supports the
> > new protocol.
> > 
> > NB: of course, I know it's a breaking-change, so it needs to be
> > properly packaged in the right version.
> > 
> > For the anecdote, I'm writing this email because of:
> > 
> > 1) What happened to me today: I was debugging a slightly complex (but
> > temporary) setup of an Haproxy being in front of MaxScale proxies
> > (mysql-specialized L7 LB) which are themself forwarding to mysql
> > daemons.
> > And the haproxy had "Layer7 wrong status: #08S01Bad handshake" errors.
> > After some hours of tests, I understood that my Haproxy was doing its
> > health-checks using the default config, so "very-old auth protocol",
> > but MaxScale only accepts the "new" protocol. It worked properly after
> > enabling the "post-41" option :)
> > If Haproxy had the "post-41" option enabled by default, I wouldn't
> > have had the issue.
> > 
> > 2) The HAProxyConf 2019 Keynote in which Willy T. talked about "Better
> > defaults" that I saw a few months ago. Because I kinda recognized my
> > issue as a (fairly minor) example of such "usability tests".
> > 
> > What do you think ?
> > 
> 
> Hi,
> 
> Reading the doc about MySQL client/server protocol, it seems possible to
> know if the server supports the 4.1 protocol or not. Thanks to the recent
> refactoring of the checks engine, it is probably possible to automatically
> use the 4.1 protocol when supported by the server. I add it on my todo list.
> But no promises about the eta.

I could be wrong but I seem to remember that the most recent version
used to require authentication, which was the reason for it not being
used by default.

However if that's the case, there's something we could do, which consists
in defaulting to 4.1 as of haproxy 2.2 when a username is provided, and
leave an option to fall back to the older version.

Like Florent, I think that by now most users have already switched to
a more recent version, and asking them to enter a keyword to indicate
that they're using something less than 16-years old is probably a bit
annoying.

Just my two cents,
Willy



Re: Suggestion: better defaults for mysql-check healthcheck (post-41 enabled)

2020-04-27 Thread Christopher Faulet

Le 27/04/2020 à 18:15, Florent Rivoire a écrit :

Hello,

This is my first message here, so: hi everyone :)
And thanks to everyone involved in the Haproxy project !

I wanted to give an idea of a (minor) better default that should be improved:
=> enable by default the "post-41" parameter in *mysql-check*

Today, it's off by default, so Haproxy is using the "very very old"
authentication method (before MySQL 4.1) to do the health-checks.
But since MySQL 4.1 is now *16* years old (stable in 2004), we are
fairly sure that all new installations of Haproxy will certainly be
used with a "recent-enough" (>= 4.1) mysql version that supports the
new protocol.

NB: of course, I know it's a breaking-change, so it needs to be
properly packaged in the right version.

For the anecdote, I'm writing this email because of:

1) What happened to me today: I was debugging a slightly complex (but
temporary) setup of an Haproxy being in front of MaxScale proxies
(mysql-specialized L7 LB) which are themself forwarding to mysql
daemons.
And the haproxy had "Layer7 wrong status: #08S01Bad handshake" errors.
After some hours of tests, I understood that my Haproxy was doing its
health-checks using the default config, so "very-old auth protocol",
but MaxScale only accepts the "new" protocol. It worked properly after
enabling the "post-41" option :)
If Haproxy had the "post-41" option enabled by default, I wouldn't
have had the issue.

2) The HAProxyConf 2019 Keynote in which Willy T. talked about "Better
defaults" that I saw a few months ago. Because I kinda recognized my
issue as a (fairly minor) example of such "usability tests".

What do you think ?



Hi,

Reading the doc about MySQL client/server protocol, it seems possible to know if 
the server supports the 4.1 protocol or not. Thanks to the recent refactoring of 
the checks engine, it is probably possible to automatically use the 4.1 protocol 
when supported by the server. I add it on my todo list. But no promises about 
the eta.


--
Christopher Faulet



Suggestion: better defaults for mysql-check healthcheck (post-41 enabled)

2020-04-27 Thread Florent Rivoire
Hello,

This is my first message here, so: hi everyone :)
And thanks to everyone involved in the Haproxy project !

I wanted to give an idea of a (minor) better default that should be improved:
=> enable by default the "post-41" parameter in *mysql-check*

Today, it's off by default, so Haproxy is using the "very very old"
authentication method (before MySQL 4.1) to do the health-checks.
But since MySQL 4.1 is now *16* years old (stable in 2004), we are
fairly sure that all new installations of Haproxy will certainly be
used with a "recent-enough" (>= 4.1) mysql version that supports the
new protocol.

NB: of course, I know it's a breaking-change, so it needs to be
properly packaged in the right version.

For the anecdote, I'm writing this email because of:

1) What happened to me today: I was debugging a slightly complex (but
temporary) setup of an Haproxy being in front of MaxScale proxies
(mysql-specialized L7 LB) which are themself forwarding to mysql
daemons.
And the haproxy had "Layer7 wrong status: #08S01Bad handshake" errors.
After some hours of tests, I understood that my Haproxy was doing its
health-checks using the default config, so "very-old auth protocol",
but MaxScale only accepts the "new" protocol. It worked properly after
enabling the "post-41" option :)
If Haproxy had the "post-41" option enabled by default, I wouldn't
have had the issue.

2) The HAProxyConf 2019 Keynote in which Willy T. talked about "Better
defaults" that I saw a few months ago. Because I kinda recognized my
issue as a (fairly minor) example of such "usability tests".

What do you think ?

-- 
Florent R.