I'm pretty sure that we are seeing "the service is down", though only
briefly. We started looking at the logs because we were seeing testing
failures and failures with our code deploys, which check the haproxy status
as part of rolling the code update to the machines. We aren't manually
having to
Hello,
I can send typo fixes weekly.
Cheers,
Ilya Shipitcin
From 6f06c0fdd87ac14e8e553ac823646d2504944f25 Mon Sep 17 00:00:00 2001
From: Ilya Shipitsin
Date: Mon, 23 Mar 2020 22:28:40 +0500
Subject: [PATCH] CLEANUP: assorted typo fixes in the code and comments
This is fifth iteration of typo fi
Hi,This patch remove #ifdef compatibility for add cert chain to CTX, goal is to simplify code.It’s an extract from "[PATCH] MINOR: ssl: skip self issued CA in cert chain for ssl_ctx » proposal.++Manu
0001-MINOR-ssl-rework-add-cert-chain-to-CTX-to-be-libssl-.patch
Description: Binary data
On Mon, Mar 23, 2020 at 03:26:20PM +0100, Emmanuel Hocdet wrote:
>
> > Le 23 mars 2020 à 15:12, William Lallemand a écrit :
> >
> > On Mon, Mar 23, 2020 at 02:50:03PM +0100, Emmanuel Hocdet wrote:
> >>
> >> As discussed in #559
> >>
> >
> > Can't we return directly a STACK_OF(X509)* structure
> Le 23 mars 2020 à 15:12, William Lallemand a écrit :
>
> On Mon, Mar 23, 2020 at 02:50:03PM +0100, Emmanuel Hocdet wrote:
>>
>> As discussed in #559
>>
>
> Can't we return directly a STACK_OF(X509)* structure instead of the
> struct issuer_chain * ?
>
> Because I have the impression that w
On Mon, Mar 23, 2020 at 02:50:03PM +0100, Emmanuel Hocdet wrote:
>
> As discussed in #559
>
Can't we return directly a STACK_OF(X509)* structure instead of the
struct issuer_chain * ?
Because I have the impression that we use the struct issuer_chain only
to lookup and we only use the chain fiel
As discussed in #559
0001-CLEANUP-ssl-rename-ssl_get_issuer_chain-to-ssl_get0_.patch
Description: Binary data
Hello Mr. Willy Tarreau ,
I have created a patch to resolve following issue
"https://github.com/haproxy/haproxy/issues/16"; .
And I have generated the patch files by following the steps defined in
"https://github.com/haproxy/haproxy/blob/master/CONTRIBUTING"; document.
Request you to please revi
On Mon, Mar 23, 2020 at 10:54:47AM +0100, Emmanuel Hocdet wrote:
>
> Hi,
>
> This issue was introduced by #516.
> find_chain must not be freed.
> patch attached.
>
> > Le 21 mars 2020 à 15:23, Илья Шипицин a écrit :
> >
> > Hello,
> >
> > I attached patch that fixes memory leak, described in
Salut Willy,
>
>> The documented values are not used on any still supported haproxy's version.
>> So I think it would be better to update the doc with the new ones
>> and add a mapping to avoid further changes.
>
> Yep definitely.
J'essaye de finir les scripts pour la gestion du SSD, et je suis
Hi,
This issue was introduced by #516.
find_chain must not be freed.
patch attached.
> Le 21 mars 2020 à 15:23, Илья Шипицин a écrit :
>
> Hello,
>
> I attached patch that fixes memory leak, described in #559
>
++
Manu
0001-BUG-MINOR-ssl-memory-leak-when-find_chain-is-NULL.patch
Descript
Hi Илья,
On Sun, Mar 22, 2020 at 2:46 PM Илья Шипицин wrote:
> Martin,
>
> as the one of the most interested in ARM64 builds, I've got news for you
>
>
> can you try
>
> travis_wait 30 bash -c 'scripts/build-ssl.sh >build-ssl.log 2>&1' || (cat
> build-ssl.log && exit 1)
>
> in travis ? (please n
Hi,
HAProxy 2.2-dev5 was released on 2020/03/23. It added 99 new commits
after version 2.2-dev4.
During these last two weeks a lot of time was spent cleaning up code,
doc and reg-tests. Fortunately in addition there are still some more
visible features:
- a unique ID may now be sent and receiv
On Mon, Mar 23, 2020 at 01:51:23PM +0500, ??? wrote:
> osx were not stable few days on travis.
> s390x also.
>
> I think to wait for few days and if it will not be repaired, we will mark
> all those as "allowed failures" for good.
Sounds good to me.
Thanks!
Willy
Hi Илья,
On Mon, Mar 23, 2020 at 10:52 AM Илья Шипицин wrote:
> well, I tried to repro abns failures on x86_64
> I chose MS Azure VM of completely different size, both number of CPU and
> RAM.
> it was never reproduced, say on 1000 execution in loop.
>
> so, I decided "it looks like something wi
osx were not stable few days on travis.
s390x also.
I think to wait for few days and if it will not be repaired, we will mark
all those as "allowed failures" for good.
пн, 23 мар. 2020 г. в 13:43, Willy Tarreau :
> Hi Ilya,
>
> I think this time I managed to fix the ABNS test. To make a long sto
well, I tried to repro abns failures on x86_64
I chose MS Azure VM of completely different size, both number of CPU and
RAM.
it was never reproduced, say on 1000 execution in loop.
so, I decided "it looks like something with memory aligning".
also, I tried to run arm64 emulation on virtualbox. no
Hi Ilya,
I think this time I managed to fix the ABNS test. To make a long story
short, it was by design extremely sensitive to the new process's startup
time, which is increased with larger FD counts and/or less powerful VMs
and/or noisy neighbors. This explains why it started to misbehave with
th
18 matches
Mail list logo