On Tue, Jun 02, 2020 at 04:25:11PM +0200, Tim Düsterhus wrote:
> This looks good to me now. I trust that you actually tested the changes.
>
> Reviewed-by: Tim Duesterhus
Argh one minute too late, just applied :-/
Thanks anyway for your review Tim!
Willy
On Tue, Jun 02, 2020 at 03:10:08PM +0200, Emeric Brun wrote:
> Thank you Tim!
>
> Here the updated patch.
Thanks guys, now applied.
Willy
Emeric,
Willy,
Am 02.06.20 um 15:10 schrieb Emeric Brun:
> Thank you Tim!
>
> Here the updated patch.
This looks good to me now. I trust that you actually tested the changes.
Reviewed-by: Tim Duesterhus
Best regards
Tim Düsterhus
Hi All,
On 6/2/20 1:10 PM, Tim Düsterhus wrote:
> Emeric,
>
> Am 02.06.20 um 11:29 schrieb Emeric Brun:
>> In attachement a proposed patch for this issue.
>>
>
> Thanks. The changes to the doc look good to me.
>
> Regarding peers.c:
>
>> +/* network key types;
>> + * network types were directl
Emeric,
Am 02.06.20 um 11:29 schrieb Emeric Brun:
> In attachement a proposed patch for this issue.
>
Thanks. The changes to the doc look good to me.
Regarding peers.c:
> +/* network key types;
> + * network types were directly and mistakenly
> + * mapped on sample types, to keep backward
> +
Hi Tim, Willy,
On 3/20/20 3:01 PM, Tim Düsterhus wrote:
> Emeric,
>
> Am 20.03.20 um 14:29 schrieb Emeric Brun:
>> So I understand that since 1.6 the SMP_T are directly announced on the wire
>> for key types, and it brokes the documented values and this is hazardous to
>> rely on internal enum v
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 Tim,
On 3/20/20 3:01 PM, Tim Düsterhus wrote:
> Emeric,
>
> Am 20.03.20 um 14:29 schrieb Emeric Brun:
>> So I understand that since 1.6 the SMP_T are directly announced on the wire
>> for key types, and it brokes the documented values and this is hazardous to
>> rely on internal enum values.
On Fri, Mar 20, 2020 at 03:12:46PM +0100, Emeric Brun wrote:
> I understood that documented values are:
> 0: signed integer
> 1: IPv4 address
> 2: IPv6 address
> 3: string
> 4: binary
>
> and currenty (since 1.6):
>2 = signed int
>4 = IPv4
>5 = IPv6
>6 = string
>7 = binary
Hi Willy,
On 3/20/20 2:53 PM, Willy Tarreau wrote:
> Hi Emeric,
>
> On Fri, Mar 20, 2020 at 02:29:48PM +0100, Emeric Brun wrote:
>> So I understand that since 1.6 the SMP_T are directly announced on the wire
>> for key types, and it brokes the documented values and this is hazardous to
>> rely on
Emeric,
Am 20.03.20 um 14:29 schrieb Emeric Brun:
> So I understand that since 1.6 the SMP_T are directly announced on the wire
> for key types, and it brokes the documented values and this is hazardous to
> rely on internal enum values.
>
> So we must re-introduce a mapping between internal an
Hi Emeric,
On Fri, Mar 20, 2020 at 02:29:48PM +0100, Emeric Brun wrote:
> So I understand that since 1.6 the SMP_T are directly announced on the wire
> for key types, and it brokes the documented values and this is hazardous to
> rely on internal enum values.
Yes that's the issue Tim spotted.
>
On 3/14/20 12:47 PM, Willy Tarreau wrote:
> On Sat, Mar 14, 2020 at 12:20:00PM +0100, Tim Düsterhus wrote:
>> Willy,
>>
>> Am 14.03.20 um 12:13 schrieb Willy Tarreau:
>>> Yes, feel free to do so, this will definitely help get it eventually done.
>>
>> Here it is: https://github.com/haproxy/haproxy/
On Sat, Mar 14, 2020 at 12:20:00PM +0100, Tim Düsterhus wrote:
> Willy,
>
> Am 14.03.20 um 12:13 schrieb Willy Tarreau:
> > Yes, feel free to do so, this will definitely help get it eventually done.
>
> Here it is: https://github.com/haproxy/haproxy/issues/548
>
> I labeled it "bug", because it
Willy,
Am 14.03.20 um 12:13 schrieb Willy Tarreau:
> Yes, feel free to do so, this will definitely help get it eventually done.
Here it is: https://github.com/haproxy/haproxy/issues/548
I labeled it "bug", because it can be considered a bug that the
on-the-wire format relies on some internal enu
On Sat, Mar 14, 2020 at 12:07:39PM +0100, Tim Düsterhus wrote:
> Willy,
>
> Am 14.03.20 um 10:13 schrieb Willy Tarreau:
> >> This is about the "Table Definition Message", more specifically the
> >> "Encoded Table Type".
> >>
> >> docs/peers-v2.0.txt says:
> >
> > There's also doc/peers.txt which
Willy,
Am 14.03.20 um 10:13 schrieb Willy Tarreau:
>> This is about the "Table Definition Message", more specifically the
>> "Encoded Table Type".
>>
>> docs/peers-v2.0.txt says:
>
> There's also doc/peers.txt which is more recent and more complete. I don't
> know if there are still some parts of
Hi Tim,
On Wed, Mar 11, 2020 at 07:44:00PM +0100, Tim Düsterhus wrote:
> Dear List
>
> I'm currently working a Peer Protocol implementation to passively
> monitor what's happening within HAProxy.
>
> The protocol specification is horribly underdocumented (docs/peers.txt
> is incomplete) and I be
Dear List
I'm currently working a Peer Protocol implementation to passively
monitor what's happening within HAProxy.
The protocol specification is horribly underdocumented (docs/peers.txt
is incomplete) and I believe I found a mistake in the existing
documentation:
This is about the "Table Defin
19 matches
Mail list logo
