Hi Olivier,
On Tue, Jan 23, 2018 at 01:39:24PM +0100, Olivier Houchard wrote:
> Willy, can you please push it ?
OK now pushed in 1.9, will backport soon.
thanks guys,
Willy
Hi William,
On Mon, Jan 22, 2018 at 08:03:55PM +0100, William Dauchy wrote:
> Hello Olivier,
>
> On Wed, Jan 17, 2018 at 05:43:02PM +0100, Olivier Houchard wrote:
> > Ok you got me convinced, the attached patch don't check for duplicate
> > cookies for disabled server, until we enable them.
>
>
Hello Olivier,
On Wed, Jan 17, 2018 at 05:43:02PM +0100, Olivier Houchard wrote:
> Ok you got me convinced, the attached patch don't check for duplicate
> cookies for disabled server, until we enable them.
I took the time to test it on top of 1.8.x and it works as expected,
removing the warnings.
On Wed, Jan 17, 2018 at 05:43:02PM +0100, Olivier Houchard wrote:
> Ok you got me convinced, the attached patch don't check for duplicate
> cookies for disabled server, until we enable them.
I also prefer this approach.
> From cfc333d2b04686a3c488fdcb495cba64dbfec14b Mon Sep 17 00:00:00 2001
> Fr
On Wed, Jan 17, 2018 at 04:42:01PM +0100, Pierre Cheynier wrote:
> On 17/01/2018 15:56, Olivier Houchard wrote:
> >
> >> So, as a conclusion, I'm just not sure that producing this warning is
> >> relevant in case the IP is duplicated for several servers *if they are
> >> disabled*...
> > Or maybe w
On 17/01/2018 15:56, Olivier Houchard wrote:
>
>> So, as a conclusion, I'm just not sure that producing this warning is
>> relevant in case the IP is duplicated for several servers *if they are
>> disabled*...
> Or maybe we should just advocate using 0.0.0.0 when we mean "no IP" :)
Not sure about t
On Wed, Jan 17, 2018 at 02:25:59PM +0100, Pierre Cheynier wrote:
> Hi,
>
> On 16/01/2018 18:48, Olivier Houchard wrote:
> >
> > Not really :) That's not a case I thought of.
> > The attached patch disables the generation of the dynamic cookie if the IP
> > is 0.0.0.0 or ::, so that it only gets ge
Hi,
On 16/01/2018 18:48, Olivier Houchard wrote:
>
> Not really :) That's not a case I thought of.
> The attached patch disables the generation of the dynamic cookie if the IP
> is 0.0.0.0 or ::, so that it only gets generated when the server gets a real
> IP. Is it OK with you ?
I'm not sure this
Hi Pierre,
On Tue, Jan 16, 2018 at 06:08:40PM +0100, Pierre Cheynier wrote:
> Hi Olivier,
>
>
> On 16/01/2018 15:43, Olivier Houchard wrote:
> > I'm not so sure about this.
> > It won't be checked again when server are enabled, so you won't get the
> > warning if it's still the case.
> > You sho
Hi Olivier,
On 16/01/2018 15:43, Olivier Houchard wrote:
> I'm not so sure about this.
> It won't be checked again when server are enabled, so you won't get the
> warning if it's still the case.
> You shouldn't get those warnings unless multiple servers have the same IP,
> though. What does your
Hi Pierre,
On Mon, Jan 15, 2018 at 06:45:52PM +0100, Pierre Cheynier wrote:
> Hello,
>
> We started to use the server-template approach in which you basically
> provision servers in backends using a "check disabled" state, then
> re-enabling them using the Runtime API.
>
> I recently noticed tha
Hello,
We started to use the server-template approach in which you basically
provision servers in backends using a "check disabled" state, then
re-enabling them using the Runtime API.
I recently noticed that when used with dynamic cookies, we end up
getting these warnings:
haproxy.c:149
12 matches
Mail list logo