Hi
I have an existing service that uses an old internal custom proxy service that
I'd like to replace with haproxy. The old system uses http1.1 style keepalive
requests and generally has a large number of long term frontend connections
(e.g. 1000 or so), but requests are relatively slow (say 1
Hello,
yet another spelling fix.
Ilya
From b3eeb7f08e1904825571406f5f4bbd7892ac2983 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Wed, 7 Dec 2022 09:46:19 +0500
Subject: [PATCH] CLEANUP: assorted typo fixes in the code and comments
This is 34th iteration of typo fixes
---
вт, 6 дек. 2022 г. в 23:29, Willy Tarreau :
> On Tue, Dec 06, 2022 at 06:59:30PM +0100, Tim Düsterhus wrote:
> > William,
> >
> > On 12/6/22 15:37, William Lallemand wrote:
> > > As I already mentionned, I don't really like the "latest" keyword for
> > > the OpenSSL version as it prevent us to
Any update on this?
William,
On 12/6/22 19:40, William Lallemand wrote:
> I disagree, porting to a new API is not something you would do just
> before a release, you need to do it progressively if possible, because
> it could introduce heavy development and sometimes discussions with the
> library developers and
Tim,
On Tue, Dec 06, 2022 at 06:59:30PM +0100, Tim Düsterhus wrote:
> > What I suggest is to stop using "latest" for the "git push" CI, but
> > using it only in a separate CI (once a day/week I don't know). And only
> > use fixed version of the libraries on the CI so builds are not broken by
> >
On Tue, Dec 06, 2022 at 06:59:30PM +0100, Tim Düsterhus wrote:
> William,
>
> On 12/6/22 15:37, William Lallemand wrote:
> > As I already mentionned, I don't really like the "latest" keyword for
> > the OpenSSL version as it prevent us to have reproducible builds.
> > It updates versions without
William,
On 12/6/22 15:37, William Lallemand wrote:
As I already mentionned, I don't really like the "latest" keyword for
the OpenSSL version as it prevent us to have reproducible builds.
It updates versions without warning, even major ones.
I agree and also was not really happy with the
вт, 6 дек. 2022 г. в 21:22, William Lallemand :
> On Tue, Dec 06, 2022 at 07:54:33PM +0500, Илья Шипицин wrote:
> > I recall I even promised to do something, but I did not :-)
> >
> > automatically determine "which is latest 3.0.x" does not make much sense,
> > it is stable branch, very
On Tue, Dec 06, 2022 at 07:54:33PM +0500, Илья Шипицин wrote:
> I recall I even promised to do something, but I did not :-)
>
> automatically determine "which is latest 3.0.x" does not make much sense,
> it is stable branch, very conservative. we can stick to 3.0.7, for example.
> I do not expect
I think I got the idea.
looks like you use the same github actions for stable branches.
either I will manage to make them different or I will stick to
3.0.something.
hopefully tomorrow
вт, 6 дек. 2022 г. в 19:54, Илья Шипицин :
> I recall I even promised to do something, but I did not :-)
>
I recall I even promised to do something, but I did not :-)
automatically determine "which is latest 3.0.x" does not make much sense,
it is stable branch, very conservative. we can stick to 3.0.7, for example.
I do not expect any breaking change between 3.0.7 and 3.0.8
we can move "latest" to
Hello,
We are experiencing difficulties with the way the CI matrix is
generated with the SSL libraries.
As I already mentionned, I don't really like the "latest" keyword for
the OpenSSL version as it prevent us to have reproducible builds.
It updates versions without warning, even major ones.
>Sorry, indeed I mentioned the enum ID and not the promex name.
>I proposed to keep "haproxy_bakcned_agg_server_check_status"
> altering its description to announce it is deprecated
>. And then to add "haproxy_backend_agg_check_status"
>aggregate haproxy_server_check_status) and
On Tue, Dec 6, 2022 at 3:27 AM Christopher Faulet wrote:
> IMHO, we should keep the current metric and its description should be updated
> to
> mention it is deprecated. This way, we will be able to remove it in the 2.9 or
> 3.0. This means we should find new names for the aggregated servers
Le 12/6/22 à 12:26, Cedric Paillet a écrit :
Sorry for the delay. We were busy because of the 2.7.0 and then I forgot your
patches :) And it was a bit late to add it into the 2.7.0.
No problem.
Because the metric name is indeed badly chosen but we can't break the
compatibility, especially
> Sorry for the delay. We were busy because of the 2.7.0 and then I forgot your
> patches :) And it was a bit late to add it into the 2.7.0.
No problem.
> Because the metric name is indeed badly chosen but we can't break the
> compatibility, especially in a LTS version.
Ok, I understand that.
Le 11/28/22 à 08:44, Cedric Paillet a écrit :
As described in github issue #1312, the first intention of patch 42d7c402d
was to aggregate haproxy_server_check_status. But we aggregated
haproxy_server_status instead.
To fix that, rename haproxy_backend_agg_server_check_status to
18 matches
Mail list logo
