❦ 14 janvier 2021 07:39 +01, ghislain:
> So, should i use basic debian backports or debian.haproxy.net
> because having both seems to collide with a boom ;p !
It's not really a conflict, but yes, you have an unecessary "downgrade"
to the same version as currently backports has 2.2.x. You can
hello everyone,
On my debians i have setup as per:
https://haproxy.debian.net/#?distribution=Debian=buster=2.2
the haproxy repo. But i have a constant issue with messages like this:
The following packages will be DOWNGRADED:
haproxy
for exemple:
The following packages will be
Hi.
When I look into the quicwg site then I miss HAProxy there ;-)
https://github.com/quicwg/base-drafts/wiki/Implementations
When do you think is the best time to add HAProxy there?
Regards
Aleks
On Wed, Jan 13, 2021 at 4:09 PM Christopher Faulet wrote:
> However, I've slightly adapted the patches, but nothing terrible. In the
> Prometheus reg-test, the bad request is tested at the end because the
> connection
> is closed on a 400-bad-request (because of a "Connection: close" header in
Hi,
HAProxy 2.2.8 was released on 2021/01/13. It added 10 new commits after
version 2.2.7.
The changelog for this release is the same than the 2.3.4. Thus, here is the
cut-paste of the 2.3.4 announce.
This new version is released less a week after the previous one to fix a
regression in the
Hi,
HAProxy 2.3.4 was released on 2021/01/13. It added 10 new commits after
version 2.3.3.
This new version is released less a week after the previous one to fix a
regression in the DNS part causing crashes. The commit 45b6d2 ("BUG/MINOR:
dns: SRV records ignores duplicated AR records") was
Le 13/01/2021 à 14:13, William Dauchy a écrit :
On Wed, Jan 13, 2021 at 1:37 PM Christopher Faulet wrote:
Just to be sure, you want to rework all the series or I can merge the first 2
patches ?
you can merge the first two patches, I think they are acceptable, and
it will be less to maintain
Le 13/01/2021 à 15:53, William Dauchy a écrit :
Hi Илья,
On Mon, Jan 11, 2021 at 8:54 PM Илья Шипицин wrote:
as far as I remember RFC, if the client sets "Connection: Close", so the server
must also close connection.
it is possible to set "Connection: close" unconditionally (as it was before
Hi Илья,
On Mon, Jan 11, 2021 at 8:54 PM Илья Шипицин wrote:
> as far as I remember RFC, if the client sets "Connection: Close", so the
> server must also close connection.
> it is possible to set "Connection: close" unconditionally (as it was before
> your patch). is it allowed to set KA
Hi,
HAProxy 1.8.28 was released on 2021/01/13. It added 33 new commits after
version 1.8.27. This new release is relatively light and contains only a
small set of fixes. Of particular interest are the following ones:
- A race condition has been fixed by Christopher affecting the leastconn
On Wed, Jan 13, 2021 at 1:37 PM Christopher Faulet wrote:
> Just to be sure, you want to rework all the series or I can merge the first 2
> patches ?
you can merge the first two patches, I think they are acceptable, and
it will be less to maintain on my local branch.
Thanks!
--
William
Le 13/01/2021 à 10:22, William Dauchy a écrit :
On Wed, Jan 13, 2021 at 9:58 AM Christopher Faulet wrote:
The first 2 patches are ok. Relying on fill_info is indeed cleaner. However, for
the last three patches, it is more annoying. The result is clean of course but
the fill_* functions will
On Wed, Jan 13, 2021 at 11:46:52AM +0100, Jerome Magnin wrote:
> On Wed, Jan 13, 2021 at 11:34:07AM +0100, William Dauchy wrote:
> > On Wed, Jan 13, 2021 at 11:06 AM William Dauchy wrote:
> > I spend some time on it, trying to find a good explanation but it
> > seems like I truly screw up. I
On Wed, Jan 13, 2021 at 11:34:07AM +0100, William Dauchy wrote:
> On Wed, Jan 13, 2021 at 11:06 AM William Dauchy wrote:
> I spend some time on it, trying to find a good explanation but it
> seems like I truly screw up. I probably overlooked the master worker
> test. So at the end forget my
On Wed, Jan 13, 2021 at 11:06 AM William Dauchy wrote:
> On Wed, Jan 13, 2021 at 10:14 AM Jerome Magnin wrote:
> > Apologies for forgetting about adding this in my commit message. Out of
> > curiosity which use case is currently covered for you ? I did most of my
> > testing on the number of FD
On Wed, Jan 13, 2021 at 10:14 AM Jerome Magnin wrote:
> Apologies for forgetting about adding this in my commit message. Out of
> curiosity which use case is currently covered for you ? I did most of my
> testing on the number of FD and wasn't able to confirm that only startup
> is broken, and
On Wed, Jan 13, 2021 at 9:58 AM Christopher Faulet wrote:
> The first 2 patches are ok. Relying on fill_info is indeed cleaner. However,
> for
> the last three patches, it is more annoying. The result is clean of course but
> the fill_* functions will then be called one time for each metric for
Hi William,
On Wed, Jan 13, 2021 at 08:57:47AM +0100, William Dauchy wrote:
> On Tue, Jan 12, 2021 at 08:36:57PM +0100, Jerome Magnin wrote:
> > From ca260ac46cd441ed4108cdef7b304b6c0baec68c Mon Sep 17 00:00:00 2001
> > From: Jerome Magnin
> > Date: Tue, 12 Jan 2021 20:19:38 +0100
> > Subject:
Le 11/01/2021 à 20:07, William Dauchy a écrit :
Hi Christopher,
This first patch set to start cleaning prometheus and reuse more of
stats.c. I know this is not yet what we aimed in terms of reuse,
especially for the defines, but this is a starting point, hoping I did
not break everything. At
19 matches
Mail list logo
