Re: Deprecating a few keywords for 2.1+

[Willy Tarreau]

On Tue, Oct 29, 2019 at 08:52:04AM +0100, Baptiste wrote:
> I was about going against as well for monitor-* keywords for now.
> There are no "simple" way to replace them currently and te 'return' thing
> will be the simple way.
> 
> Note that you can use a Lua service for this purpose currently, but it's
> not as simple as having a single small directive in an HAProxy config file.

I agree. And I initially forgot about the monitor-fail ruleset (which I
thought was a single rule), which will not be trivial to convert and mix
with other rules. Maybe in the future we'll "emulate" them by creating
dummy http-request rules, but probably that the directives should stay.

Willy

Re: Deprecating a few keywords for 2.1+

[Baptiste]

I was about going against as well for monitor-* keywords for now.
There are no "simple" way to replace them currently and te 'return' thing
will be the simple way.

Note that you can use a Lua service for this purpose currently, but it's
not as simple as having a single small directive in an HAProxy config file.

Baptiste


On Tue, Oct 29, 2019 at 4:34 AM Willy Tarreau  wrote:

> On Tue, Oct 29, 2019 at 12:40:52AM +0100, Aleksandar Lazic wrote:
> > > Or maybe something like:
> > > http-request deny deny_status 500 if { path_beg /health } {
> nbsrv(yourbackend) lt 1 }
> > > http-request deny deny_status 200 if { path_beg /health }
> >
> > Looks good but 'deny' and '200' feels wrong.
> >
> > Maybe we should have a 'http-request monitor ...' which replaces the
> monitor* stuff?
>
> Well, guys you convinced me for monitor-uri. We still don't have the
> "return" directive which would have been more suitable for this, but
> in any case I agree that transcoding the monitor-fail rules to anything
> else will be painful.
>
> Also, the code dealing with monitor-uri isn't the ugliest one as it's
> still handled by the streams and could be converted to HTX lately. It's
> just that seeing it being tested in the CLI code irritates me a little
> bit.
>
> However, for "mode health" and "monitor-net", it's another story and
> these ones cannot work in SSL nor with muxes :-/
>
> To give you an idea, this is what we have in the FD accept code :
>
> if (p->mode == PR_MODE_HTTP ||
> (p->mode == PR_MODE_HEALTH && (p->options2 & PR_O2_CHK_ANY) ==
> PR_O2_HTTP_CHK))
> send(cfd, "HTTP/1.0 200 OK\r\n\r\n", 19,
> MSG_DONTWAIT|MSG_NOSIGNAL|MSG_MORE);
> else if (p->mode == PR_MODE_HEALTH)
> send(cfd, "OK\n", 3, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_MORE);
>
> Sending these ones raw on the socket with SSL or H2 makes no sense, and
> I'd rather stop hacking the socket at this level. That's why I'm really
> impatient to drop these ones.
>
> Thanks,
> Willy
>
>

Re: Deprecating a few keywords for 2.1+

[Willy Tarreau]

On Tue, Oct 29, 2019 at 12:40:52AM +0100, Aleksandar Lazic wrote:
> > Or maybe something like:
> > http-request deny deny_status 500 if { path_beg /health } { 
> > nbsrv(yourbackend) lt 1 }
> > http-request deny deny_status 200 if { path_beg /health }
> 
> Looks good but 'deny' and '200' feels wrong.
> 
> Maybe we should have a 'http-request monitor ...' which replaces the monitor* 
> stuff?

Well, guys you convinced me for monitor-uri. We still don't have the
"return" directive which would have been more suitable for this, but
in any case I agree that transcoding the monitor-fail rules to anything
else will be painful.

Also, the code dealing with monitor-uri isn't the ugliest one as it's
still handled by the streams and could be converted to HTX lately. It's
just that seeing it being tested in the CLI code irritates me a little
bit.

However, for "mode health" and "monitor-net", it's another story and
these ones cannot work in SSL nor with muxes :-/

To give you an idea, this is what we have in the FD accept code :

if (p->mode == PR_MODE_HTTP ||
(p->mode == PR_MODE_HEALTH && (p->options2 & PR_O2_CHK_ANY) == 
PR_O2_HTTP_CHK))
send(cfd, "HTTP/1.0 200 OK\r\n\r\n", 19, 
MSG_DONTWAIT|MSG_NOSIGNAL|MSG_MORE);
else if (p->mode == PR_MODE_HEALTH)
send(cfd, "OK\n", 3, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_MORE);

Sending these ones raw on the socket with SSL or H2 makes no sense, and
I'd rather stop hacking the socket at this level. That's why I'm really
impatient to drop these ones.

Thanks,
Willy

Re: Deprecating a few keywords for 2.1+

[Aleksandar Lazic]

Am 28.10.2019 um 17:44 schrieb Jarno Huuskonen:

On Mon, Oct 28, Aleksandar Lazic wrote:

Am 27.10.2019 um 20:16 schrieb David Birdsong:

I'm just curious: what replaces monitor-uri? I'm putting up a new proxy
tier at my new company and can steer to use the more up-to-date method,
but combing the docs and nothing jumps out at me.

I'm guessing something in either http-re{quest,response}, but I don't
see anything that synthesizes responses in there.


I would think about to use errorfile for this.

https://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4-errorfile

Could this work?

```
global
   ...
default
   ...
frontend
   ...
   use_backend b_health if { path_beg /health }
   ...

backend b_health
   errorfile 200 /etc/haproxy/errorfiles/200health.http
   ...

```


Or maybe something like:
http-request deny deny_status 500 if { path_beg /health } { nbsrv(yourbackend) 
lt 1 }
http-request deny deny_status 200 if { path_beg /health }


Looks good but 'deny' and '200' feels wrong.

Maybe we should have a 'http-request monitor ...' which replaces the monitor* 
stuff?


-Jarno


On Sat, Oct 26, 2019 at 8:14 AM Willy Tarreau mailto:w...@1wt.eu>> wrote:

 Hi,

 a few months ago while working on cleaning up and stabilizing the
 connection layers, I figured that we still have ugly hacks bypassing
 the whole stack around the "mode health", "monitor-net" and "monitor-uri"
 directives, that were all used to respond to health checks from an
 external LB. Since SSL was introduced, these started not to make much
 sense anymore, with raw data being sent directly to the socket and
 bypassing the SSL stack, and now with muxes it's even worse.

 Given their obvious obsolescence I don't expect anyone to be using these
 anymore and to have switched to other mechanisms like HTTP redirects,
 errorfiles or Lua instead which are all way more versatile and
 configurable.

 Thus I was thinking about marking them deprecated for 2.1 and then
 removing them from 2.3. Or even better, removing them from 2.1, but
 since we have not sent a prior deprecation warning, it would really
 require confirmation that really nobody is using them at all anymore
 (which I think is likely the case starting with 1.5).

 Any opinion on this ?

 Thanks,
 Willy

Re: Deprecating a few keywords for 2.1+

[Aleksandar Lazic]

Am 28.10.2019 um 17:43 schrieb David Birdsong:



On Mon, Oct 28, 2019 at 12:27 PM Aleksandar Lazic > wrote:


Am 27.10.2019 um 20:16 schrieb David Birdsong:
 > I'm just curious: what replaces monitor-uri? I'm putting up a new proxy
tier at
 > my new company and can steer to use the more up-to-date method, but
combing the
 > docs and nothing jumps out at me.
 >
 > I'm guessing something in either http-re{quest,response}, but I don't see
 > anything that synthesizes responses in there.

I would think about to use errorfile for this.

https://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4-errorfile

Could this work?

```
global
    ...
default
    ...
frontend
    ...
    use_backend b_health if { path_beg /health }
    ...

backend b_health
    errorfile 200 /etc/haproxy/errorfiles/200health.http
    ...

```


my understanding is that errorfile   just sets the full http 
response for a given synthesized code, but doesn't actually cause haproxy to not 
send to a backend server and return the value for the code specified.


woudn't this return a 503, "no servers" response?


Could be, the above was just a brainstorming.


also, what would replace `monitor fail if {stopping}`?


maybe Jarno suggestion is a better way to go.


Regards
Aleks

 > On Sat, Oct 26, 2019 at 8:14 AM Willy Tarreau mailto:w...@1wt.eu>
>> wrote:
 >
 >     Hi,
 >
 >     a few months ago while working on cleaning up and stabilizing the
 >     connection layers, I figured that we still have ugly hacks bypassing
 >     the whole stack around the "mode health", "monitor-net" and 
"monitor-uri"
 >     directives, that were all used to respond to health checks from an
 >     external LB. Since SSL was introduced, these started not to make much
 >     sense anymore, with raw data being sent directly to the socket and
 >     bypassing the SSL stack, and now with muxes it's even worse.
 >
 >     Given their obvious obsolescence I don't expect anyone to be using 
these
 >     anymore and to have switched to other mechanisms like HTTP redirects,
 >     errorfiles or Lua instead which are all way more versatile and
 >     configurable.
 >
 >     Thus I was thinking about marking them deprecated for 2.1 and then
 >     removing them from 2.3. Or even better, removing them from 2.1, but
 >     since we have not sent a prior deprecation warning, it would really
 >     require confirmation that really nobody is using them at all anymore
 >     (which I think is likely the case starting with 1.5).
 >
 >     Any opinion on this ?
 >
 >     Thanks,
 >     Willy
 >

Re: Deprecating a few keywords for 2.1+

[Jarno Huuskonen]

On Mon, Oct 28, Aleksandar Lazic wrote:
> Am 27.10.2019 um 20:16 schrieb David Birdsong:
> > I'm just curious: what replaces monitor-uri? I'm putting up a new proxy
> > tier at my new company and can steer to use the more up-to-date method,
> > but combing the docs and nothing jumps out at me.
> > 
> > I'm guessing something in either http-re{quest,response}, but I don't
> > see anything that synthesizes responses in there.
> 
> I would think about to use errorfile for this.
> 
> https://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4-errorfile
> 
> Could this work?
> 
> ```
> global
>   ...
> default
>   ...
> frontend
>   ...
>   use_backend b_health if { path_beg /health }
>   ...
> 
> backend b_health
>   errorfile 200 /etc/haproxy/errorfiles/200health.http
>   ...
> 
> ```

Or maybe something like:
http-request deny deny_status 500 if { path_beg /health } { nbsrv(yourbackend) 
lt 1 }
http-request deny deny_status 200 if { path_beg /health }

-Jarno

> > On Sat, Oct 26, 2019 at 8:14 AM Willy Tarreau  > > wrote:
> > 
> > Hi,
> > 
> > a few months ago while working on cleaning up and stabilizing the
> > connection layers, I figured that we still have ugly hacks bypassing
> > the whole stack around the "mode health", "monitor-net" and 
> > "monitor-uri"
> > directives, that were all used to respond to health checks from an
> > external LB. Since SSL was introduced, these started not to make much
> > sense anymore, with raw data being sent directly to the socket and
> > bypassing the SSL stack, and now with muxes it's even worse.
> > 
> > Given their obvious obsolescence I don't expect anyone to be using these
> > anymore and to have switched to other mechanisms like HTTP redirects,
> > errorfiles or Lua instead which are all way more versatile and
> > configurable.
> > 
> > Thus I was thinking about marking them deprecated for 2.1 and then
> > removing them from 2.3. Or even better, removing them from 2.1, but
> > since we have not sent a prior deprecation warning, it would really
> > require confirmation that really nobody is using them at all anymore
> > (which I think is likely the case starting with 1.5).
> > 
> > Any opinion on this ?
> > 
> > Thanks,
> > Willy
> > 
> 
> 

-- 
Jarno Huuskonen

Re: Deprecating a few keywords for 2.1+

[David Birdsong]

On Mon, Oct 28, 2019 at 12:27 PM Aleksandar Lazic 
wrote:

> Am 27.10.2019 um 20:16 schrieb David Birdsong:
> > I'm just curious: what replaces monitor-uri? I'm putting up a new proxy
> tier at
> > my new company and can steer to use the more up-to-date method, but
> combing the
> > docs and nothing jumps out at me.
> >
> > I'm guessing something in either http-re{quest,response}, but I don't
> see
> > anything that synthesizes responses in there.
>
> I would think about to use errorfile for this.
>
> https://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4-errorfile
>
> Could this work?
>
> ```
> global
>...
> default
>...
> frontend
>...
>use_backend b_health if { path_beg /health }
>...
>
> backend b_health
>errorfile 200 /etc/haproxy/errorfiles/200health.http
>...
>
> ```
>

my understanding is that errorfile   just sets the full http
response for a given synthesized code, but doesn't actually cause haproxy
to not send to a backend server and return the value for the code specified.

woudn't this return a 503, "no servers" response?

also, what would replace `monitor fail if {stopping}`?

>
> Regards
> Aleks
>
> > On Sat, Oct 26, 2019 at 8:14 AM Willy Tarreau  > >
> wrote:
> >
> > Hi,
> >
> > a few months ago while working on cleaning up and stabilizing the
> > connection layers, I figured that we still have ugly hacks bypassing
> > the whole stack around the "mode health", "monitor-net" and
> "monitor-uri"
> > directives, that were all used to respond to health checks from an
> > external LB. Since SSL was introduced, these started not to make much
> > sense anymore, with raw data being sent directly to the socket and
> > bypassing the SSL stack, and now with muxes it's even worse.
> >
> > Given their obvious obsolescence I don't expect anyone to be using
> these
> > anymore and to have switched to other mechanisms like HTTP redirects,
> > errorfiles or Lua instead which are all way more versatile and
> > configurable.
> >
> > Thus I was thinking about marking them deprecated for 2.1 and then
> > removing them from 2.3. Or even better, removing them from 2.1, but
> > since we have not sent a prior deprecation warning, it would really
> > require confirmation that really nobody is using them at all anymore
> > (which I think is likely the case starting with 1.5).
> >
> > Any opinion on this ?
> >
> > Thanks,
> > Willy
> >
>
>

Re: Deprecating a few keywords for 2.1+

[Aleksandar Lazic]

Am 27.10.2019 um 20:16 schrieb David Birdsong:
I'm just curious: what replaces monitor-uri? I'm putting up a new proxy tier at 
my new company and can steer to use the more up-to-date method, but combing the 
docs and nothing jumps out at me.


I'm guessing something in either http-re{quest,response}, but I don't see 
anything that synthesizes responses in there.


I would think about to use errorfile for this.

https://cbonte.github.io/haproxy-dconv/2.1/configuration.html#4-errorfile

Could this work?

```
global
  ...
default
  ...
frontend
  ...
  use_backend b_health if { path_beg /health }
  ...

backend b_health
  errorfile 200 /etc/haproxy/errorfiles/200health.http
  ...

```

Regards
Aleks


On Sat, Oct 26, 2019 at 8:14 AM Willy Tarreau mailto:w...@1wt.eu>> wrote:

Hi,

a few months ago while working on cleaning up and stabilizing the
connection layers, I figured that we still have ugly hacks bypassing
the whole stack around the "mode health", "monitor-net" and "monitor-uri"
directives, that were all used to respond to health checks from an
external LB. Since SSL was introduced, these started not to make much
sense anymore, with raw data being sent directly to the socket and
bypassing the SSL stack, and now with muxes it's even worse.

Given their obvious obsolescence I don't expect anyone to be using these
anymore and to have switched to other mechanisms like HTTP redirects,
errorfiles or Lua instead which are all way more versatile and
configurable.

Thus I was thinking about marking them deprecated for 2.1 and then
removing them from 2.3. Or even better, removing them from 2.1, but
since we have not sent a prior deprecation warning, it would really
require confirmation that really nobody is using them at all anymore
(which I think is likely the case starting with 1.5).

Any opinion on this ?

Thanks,
Willy

Re: Deprecating a few keywords for 2.1+

[David Birdsong]

I'm just curious: what replaces monitor-uri? I'm putting up a new proxy
tier at my new company and can steer to use the more up-to-date method, but
combing the docs and nothing jumps out at me.

I'm guessing something in either http-re{quest,response}, but I don't see
anything that synthesizes responses in there.

On Sat, Oct 26, 2019 at 8:14 AM Willy Tarreau  wrote:

> Hi,
>
> a few months ago while working on cleaning up and stabilizing the
> connection layers, I figured that we still have ugly hacks bypassing
> the whole stack around the "mode health", "monitor-net" and "monitor-uri"
> directives, that were all used to respond to health checks from an
> external LB. Since SSL was introduced, these started not to make much
> sense anymore, with raw data being sent directly to the socket and
> bypassing the SSL stack, and now with muxes it's even worse.
>
> Given their obvious obsolescence I don't expect anyone to be using these
> anymore and to have switched to other mechanisms like HTTP redirects,
> errorfiles or Lua instead which are all way more versatile and
> configurable.
>
> Thus I was thinking about marking them deprecated for 2.1 and then
> removing them from 2.3. Or even better, removing them from 2.1, but
> since we have not sent a prior deprecation warning, it would really
> require confirmation that really nobody is using them at all anymore
> (which I think is likely the case starting with 1.5).
>
> Any opinion on this ?
>
> Thanks,
> Willy
>
>