Re: testing and validating complex haproxy.conf rules
On Tue, 31 Mar 2020, at 07:53, Aleksandar Lazic wrote:
> Hi Dave.
>
> On 31.03.20 09:24, Dave Cottlehuber wrote:
> > hi all,
> >
> > Our main haproxy.conf has practically become sentient... it's reached the
> > point where the number of url redirects and similar incantations is very
> > hard to reason about, and certainly not test or validate, until it's
> > shipped. In fact I deploy to a "B" cluster node, and verify most changes
> > on a spare production node. This is not always possible to ensure that
> > existing acls and url redirects aren't broken by the changes.
> >
> > For example:
> >
> > https://%[hdr(host)]%[url,regsub(/$,)] ...
> >
> > didn't do what the person who deployed it thinks it does - easy enough to
> > fix. How could we have tested this locally before committing it?
> >
> > Is there any easy-ish way to try out these rules, almost like you
> > could in a REPL?
> >
> > Once we've written them, and committed them to our ansible repos, is there
> > any way to unit test the whole config, to avoid regressions?
> >
> > 90% of these commits relate to remapping and redirecting urls from patterns.
>
> Please can you tell us which version of HAProxy and some more details
> from the config.
> Maybe you can split the redirects, for example can you use a map for
> the host part.
thanks Aleks,
In this case it's haproxy 2.1, and the config is complex.
This is a generic problem, not one for a single rule -- I need to find a way
to enable other people "unit test" their changes, before committing, and,
once committed, to avoid breaking production, be able to validate that the
most recent change doesn't break existing functions (more unit tests but
over the whole config). I can spin up a full staging environment if
necessary but I'm hoping somebody has a clever hack to avoid this.
Our newer stuff looks a bit like this with a map file:
http-requestredirect code 301 location
%[capture.req.uri,map(/usr/local/etc/haproxy/redirects.map)] if {
capture.req.uri,map(/usr/local/etc/haproxy/redirects.map) -m found }
but there are hundreds of acls that can overlap, or even override the
straightforward logic of the map. That's what I need to find a way to deal with.
A+
Dave
Re: [PATCH] MINOR: ssl: skip self issued CA in cert chain for ssl_ctx
On Thu, Mar 26, 2020 at 06:29:48PM +0100, William Lallemand wrote: > > After some thinking and discussing with people involved in this part of > HAProxy. I'm not feeling very confortable with setting this behavior by > default, on top on that the next version is an LTS so its not a good > idea to change this behavior yet. I think in most case it won't be a > problem but it would be better if it's enabled by an option in the > global section. > Hi Manu, Could you take a look at this? Because I already merged your first patch, so if we don't do anything about it we may revert it before the release. Thanks a lot! -- William Lallemand
Re: [PATCH] DOC: internals: Fix spelling errors in filters.txt
On Thu, Mar 26, 2020 at 08:51:03PM +0100, Miroslav Zagorac wrote: > Hello, > > here is attached the patch that corrects several spelling errors in > doc/internals/filters.txt document. Thanks Miroslav, now merged. Willy
Re: [PATCH] BUG/MINOR: stats: Fix color of draining servers on stats page
On Sat, Mar 28, 2020 at 12:54:39PM -0400, Daniel Corbett wrote: > This patch fixes #53 where it was noticed that when an active > server is set to DRAIN it no longer has the color blue reflected > within the stats page. This patch addresses that and adds the > color back to drain. It's to be noted that backup servers are > configured to have an orange color when they are draining. Thanks Daniel, now merged! Willy
Re: stable-bot: Bugfixes waiting for a release 2.1 (21), 2.0 (16)
On 31 Mar 17:14, Willy Tarreau wrote: > On Tue, Mar 24, 2020 at 04:46:43PM +0100, Tim Düsterhus wrote: > > > Could you please cut a release ? there are many fixes that just cherry > > > picking it in my fork would make sense. > > > > I second that. I was already thinking about asking after yesterday's > > 2.2-dev5. > > I'm aiming at Thursday. Still working on the backports. I know sometimes > we're lagging behind a lot, but when you consider that backports can take > up to 50% of the work time, and more importantly that many times it can > divert you by 3 hours for something that was expected to take 10 seconds, > it's easy to understand why they're often handled in batches :-/ > > Willy No worries. The goal is not to put pressure on the maintainers, also I did not insist after my first mail. Take your time, thanks! -- (o-Julien Pivotto //\Open-Source Consultant V_/_ Inuits - https://www.inuits.eu signature.asc Description: PGP signature
Re: [PATCH] MINOR: config: make strict limits enabled by default
Hi guys, On Sat, Mar 28, 2020 at 09:09:17PM +0100, Tim Düsterhus wrote: > William, > > Am 28.03.20 um 19:32 schrieb William Dauchy: > > On Sat, Mar 28, 2020 at 7:29 PM Lukas Tribus wrote: > >> master is still for 2.2 which is in development. If you want to target > >> v2.3, you have to wait until 2.2 is released. > > > > oh true, I'm mixing versions, probably because we already started to > > deploy part of v2.2... > > > > Sorry for that, please ignore this patch :) > > > > For 2.1 we used the 'next' branch to already take these type of patches. You're right, and I've just updated it now with v2 of this patch. We'll progressively start to queue new patches into -next now. It will get rebased from time to time. Thanks! Willy
Re: stable-bot: Bugfixes waiting for a release 2.1 (21), 2.0 (16)
On Tue, Mar 24, 2020 at 04:46:43PM +0100, Tim Düsterhus wrote: > > Could you please cut a release ? there are many fixes that just cherry > > picking it in my fork would make sense. > > I second that. I was already thinking about asking after yesterday's > 2.2-dev5. I'm aiming at Thursday. Still working on the backports. I know sometimes we're lagging behind a lot, but when you consider that backports can take up to 50% of the work time, and more importantly that many times it can divert you by 3 hours for something that was expected to take 10 seconds, it's easy to understand why they're often handled in batches :-/ Willy
Re: [PATCH] 5th iteration of typo fixes
On Mon, Mar 23, 2020 at 10:32:29PM +0500, ??? wrote: > Hello, > > I can send typo fixes weekly. Thanks Ilya, now merged! Willy
Re: [PR] Add missing string length for lua sticktable lookup
Hi Nathan, On Mon, Mar 30, 2020 at 02:12:26AM +, Neulinger, Nathan wrote: > Willy, I never saw any response to this - and don't think any of my responses > to you ever showed up on the mailing list archive either. Indeed, I never saw this one. I'll have a look at your resent message shortly, I need to dive into its context again, and will do it after I'm done on the pending backports. Thanks! Willy
Want to be on top of Search Results?
*Hello,* Hope this email finds you well. I would like to know if you got my last email Regarding the SEO campaign. If yes! Please update me on your thoughts for the same, so that we could discuss further and initiate this campaign shortly. Look forward to hearing from you soon. Best Regards, *Jaclyn Smith Internet Marketer* *--* *Note: *If you are not interested to hire our services then reply to this email with the subject line*“NOT INTERESTED”.* [image: beacon]
Re: testing and validating complex haproxy.conf rules
Hi Dave. On 31.03.20 09:24, Dave Cottlehuber wrote: hi all, Our main haproxy.conf has practically become sentient... it's reached the point where the number of url redirects and similar incantations is very hard to reason about, and certainly not test or validate, until it's shipped. In fact I deploy to a "B" cluster node, and verify most changes on a spare production node. This is not always possible to ensure that existing acls and url redirects aren't broken by the changes. For example: https://%[hdr(host)]%[url,regsub(/$,)] ... didn't do what the person who deployed it thinks it does - easy enough to fix. How could we have tested this locally before committing it? Is there any easy-ish way to try out these rules, almost like you could in a REPL? Once we've written them, and committed them to our ansible repos, is there any way to unit test the whole config, to avoid regressions? 90% of these commits relate to remapping and redirecting urls from patterns. Please can you tell us which version of HAProxy and some more details from the config. Maybe you can split the redirects, for example can you use a map for the host part. A+ Dave Regards Aleks
testing and validating complex haproxy.conf rules
hi all, Our main haproxy.conf has practically become sentient... it's reached the point where the number of url redirects and similar incantations is very hard to reason about, and certainly not test or validate, until it's shipped. In fact I deploy to a "B" cluster node, and verify most changes on a spare production node. This is not always possible to ensure that existing acls and url redirects aren't broken by the changes. For example: https://%[hdr(host)]%[url,regsub(/$,)] ... didn't do what the person who deployed it thinks it does - easy enough to fix. How could we have tested this locally before committing it? Is there any easy-ish way to try out these rules, almost like you could in a REPL? Once we've written them, and committed them to our ansible repos, is there any way to unit test the whole config, to avoid regressions? 90% of these commits relate to remapping and redirecting urls from patterns. A+ Dave
