hello,
here's another CI patch (which skips alpn testing on CentOS 6)
пт, 6 сент. 2019 г. в 15:48, Илья Шипицин :
> great.
>
> I'll resolve ALPN testing soon. let those builds be red for a while.
>
> пт, 6 сент. 2019 г. в 14:45, Willy Tarreau :
>
>> On Mon, Sep 02, 2019 at 12:10:11AM +0500,
Dear List
something between 02bac85bee664976f6dcecc424864e9fb99975be and
f909c91e8a739b9ef7409b399259201fe883771c broke all the Linux builds on
Travis CI:
- 41 reg tests fail with a timeout
- 3 reg tests pass
FreeBSD works fine.
Somebody really ought to take a look. I might try to bisect if I
Dear list!
Author: Mickaël Martin
Number of patches: 1
This is an automated relay of the Github pull request:
Add support for server maintenance
Patch title(s):
Add support for server maintenance
Link:
https://github.com/haproxy/haproxy/pull/261
Edit locally:
wget
great.
I'll resolve ALPN testing soon. let those builds be red for a while.
пт, 6 сент. 2019 г. в 14:45, Willy Tarreau :
> On Mon, Sep 02, 2019 at 12:10:11AM +0500, ??? wrote:
> > please review the following patch
>
> No particular opinion on it so I merged it.
>
> Thanks Ilya.
> Willy
Hi Sven,
First, thanks for this contribution and the detailed description.
On Tue, Sep 03, 2019 at 12:23:04PM +, PR Bot wrote:
> Description:
>Add configuration parameters to control TCP keep-alives:
>* tcp-
>keepalive-time: Idle time before keep-alive probes are sent
>* tcp-
On Mon, Sep 02, 2019 at 12:10:11AM +0500, ??? wrote:
> please review the following patch
No particular opinion on it so I merged it.
Thanks Ilya.
Willy
On Fri, Sep 06, 2019 at 11:33:32AM +0200, Geoff Simmons wrote:
> On 9/6/19 11:22, Willy Tarreau wrote:
> >
> > We can then have 4 being the only one implemented for now, we can then
> > set it to the default one if unspecified, but I really want to support
> > such a parameter so that it's easy
On Fri, Sep 06, 2019 at 11:04:44AM +0200, Tim Düsterhus wrote:
> Willy,
> Luca,
>
> Am 06.09.19 um 05:17 schrieb Willy Tarreau:
> >> smp->data.type = SMP_T_STR;
> >> smp->flags = SMP_F_MAY_CHANGE;
>
> Comparing this with the time fetches I believe there is 'SMP_F_VOL_TEST'
> missing, no?
Hi everybody!
Any news on this issue? Maybe you need some more detailed info? I still
getting these errors on instances with high request rates.
чт, 29 авг. 2019 г. в 14:21, Максим Куприянов :
> Hi!
>
> Sometimes on reload of 2.0.5 I got this in logs:
> A bogus APPCTX [0x7fc1a06ff0e0] is
On 9/6/19 11:22, Willy Tarreau wrote:
>
> We can then have 4 being the only one implemented for now, we can then
> set it to the default one if unspecified, but I really want to support
> such a parameter so that it's easy to extend the form once a new one
> arrives.
Still picking nits (although
Willy,
Am 06.09.19 um 11:22 schrieb Willy Tarreau:
> That's what I really meant in order to support different formats that
> one would like to implement, without having to be exclusively tied to
> those described in RFC4122. But after thinking a bit about it, I guess
> that if most users expect
On Fri, Sep 06, 2019 at 10:54:41AM +0200, Tim Düsterhus wrote:
> Willy,
>
> Am 06.09.19 um 10:48 schrieb Willy Tarreau:
> > Let's simply declare that uuid(1) follows the v4 format of RFC4122 with
> > all fields random. Then we may add new types later on when needed.
>
> I'm not sure whether
Hi,
On Thu, Sep 05, Sander Klein wrote:
> I was looking at implementing rate limiting in our setup. But, since we are
> handling both IPv4 and IPv6 in the same frontends and backends, I was
> wondering how I could do that.
>
> AFAIK a stick table is either IPv4 or IPv6 and you can only have one
Willy,
Luca,
Am 06.09.19 um 05:17 schrieb Willy Tarreau:
>> smp->data.type = SMP_T_STR;
>> smp->flags = SMP_F_MAY_CHANGE;
Comparing this with the time fetches I believe there is 'SMP_F_VOL_TEST'
missing, no?
>> smp->data.type = SMP_T_STR;
>> smp->data.u.str.area =
Willy,
Am 06.09.19 um 10:48 schrieb Willy Tarreau:
> Let's simply declare that uuid(1) follows the v4 format of RFC4122 with
> all fields random. Then we may add new types later on when needed.
I'm not sure whether that's a typo, but I'd suggest `uuid(4)` for a
version 4 UUID.
Best regards
Tim
On Fri, Sep 06, 2019 at 10:35:08AM +0200, Geoff Simmons wrote:
> On 9/6/19 09:57, Schimweg, Luca wrote:
> >
> > UUIDs generally have different versions. I implemented version 4
> > right now, but if you want to we can implement different UUID types.
> > I personally think one is enough, because
On 9/6/19 09:57, Schimweg, Luca wrote:
>
> UUIDs generally have different versions. I implemented version 4
> right now, but if you want to we can implement different UUID types.
> I personally think one is enough, because most people won't care if
> they get an UUID v1, v2, ...,
I agree with
Hey Willy,
thanks for the suggestions, I'll integrate them later or on monday.
UUIDs generally have different versions. I implemented version 4 right now, but
if you want to we can implement different UUID types. I personally think one is
enough, because most people won't care if they get an
18 matches
Mail list logo
