Re: lua workers and peer stick tables

[Willy Tarreau]

Hi Dave,

On Thu, Sep 08, 2022 at 01:20:57AM +, Dave Cottlehuber wrote:
> The second part, is it possible to access peer stick tables?
> 
> I don't see them in the objects listed by Thierry, nor when recursively
> dumping the core object.
> 
> https://www.arpalert.org/src/haproxy-lua-api/2.6/#external-lua-libraries

I'm far from being a specialist of the Lua part, but to the best of my
knowledge, there's no binding for stick-tables (there are even a few
issues opened here and there about adding this or that binding to Lua).

If you just need to read the table, you should have a look at the
possibility to call some sample fetch functions or converters that are
able to access stick-tables. For example, table_http_req_rate() and
friends. This one takes a sample on input that is looked up as a key
in the designated table and returns the value. Converters and sample
fetch functions can be called from Lua. I never know how to use them
but I know it's possible. Please have a look at "TXN.c" in the Lua
doc above, you should understand how to proceed better than me :-)

Hoping this helps,
Willy

Re: [PATCH] Allow disabling "option forwardfor"

[Willy Tarreau]

Hi Samuel,

On Thu, Sep 08, 2022 at 09:04:22AM +0200, Samuel Maftoul wrote:
> Hi,
> 
> This is the continuation of a discussion that happened on github (
> https://github.com/haproxy/haproxy/pull/1853).

Thanks for this.

> Here, I applied Willy's 3rd proposal: adding a keyword to the forwardfor
> option to disable the header. I used 'none' as the keyword, as I looked in
> the documentation to see if I should use 'disable' or 'disabled', it looked
> to me 'disable' is more consistent, but 'none' is even more consistent (we
> already have options using 'none' as keyword, but no option uses 'disable'
> as keyword).
> 
> Also, the implementation is simpler than what was proposed in the PR,
> Christopher, I think I don't need to free anything, and also , I added the
> edge case you cited as a test.
> 
> Is this approach right ?

I think the approach is right, however I suspect that it won't work if
the option is enabled in the frontend, which I understood was the initial
concern. In your case it will only disable it if it was present in the
defaults section, which a "no option ..." should handle right.

If we want to cover the cancellation of a frontend option, I suspect that
we need to set a flag on the backend to indicate that the header must not
be added when the request leaves, so that it can cancel a possible
forwardfor in the frontend.

So there are two possibilities:
  - "no option ..." => revert to default settings for the option, i.e.
do not force it enabled, which means that it can revert what appears
in the defaults section, but that frontend presence remains sufficient
to enable itx

  - "option forwardfor none" => explicitly disable XFF addition for requests
flowing through this backend, even if they passed through a frontend
which had the option explicitly enabled.

We can even make sure to support both, by the way, if "no option..." does
not work right now.

Hoping this clarifies it a little bit,
Willy

Re: [PATCH] cirrus-ci: bump FreeBSD image to 13.1

[Willy Tarreau]

On Fri, Sep 09, 2022 at 12:27:09PM +0200, Tim Düsterhus wrote:
> Willy,
> 
> On 9/8/22 19:04,  ??? wrote:
> > as we install freebsd binary packages, we need to bump image from time to
> > time
> > to match prebuilt packages.
> > 
> 
> The patch LGTM and should unbreak CI. Please take it.

Applied and pushed, thank you both!
Willy

Re: [PATCH] cirrus-ci: bump FreeBSD image to 13.1

[Tim Düsterhus]

Willy,

On 9/8/22 19:04, Илья Шипицин wrote:

as we install freebsd binary packages, we need to bump image from time to
time
to match prebuilt packages.



The patch LGTM and should unbreak CI. Please take it.

Best regards
Tim Düsterhus