Hey Willy,
thanks so much!
Best regards
Luca
On 13.09.19, 04:48, "Willy Tarreau" wrote:
Hi Luca,
On Wed, Sep 11, 2019 at 10:31:27AM +, Schimweg, Luca wrote:
> Hey Tim,
>
> Thanks, I missed the empty line. Fixed it
> Yeah, the email is correct. There is no
Hi Luca,
On Wed, Sep 11, 2019 at 10:31:27AM +, Schimweg, Luca wrote:
> Hey Tim,
>
> Thanks, I missed the empty line. Fixed it
> Yeah, the email is correct. There is no github.com account associated with
> this email, so I'll use my private email to commit, which has a github.com
> account.
Hey Tim,
Thanks, I missed the empty line. Fixed it
Yeah, the email is correct. There is no github.com account associated with this
email, so I'll use my private email to commit, which has a github.com account.
Best regards
Luca
On 11.09.19, 12:26, "Tim Düsterhus" wrote:
Luca,
Luca,
Am 11.09.19 um 09:40 schrieb Schimweg, Luca:
> thanks for the feedback. I included the changes in the updated patch.
>
Something went wrong with the commit message:
> Subject: [PATCH] MINOR: sample: Add UUID-fetch Adds the fetch uuid(int). New
> feature, but could be backported
Did you
Hey,
thanks for the feedback. I included the changes in the updated patch.
Best regards
Luca
On 11.09.19, 08:52, "Willy Tarreau" wrote:
On Tue, Sep 10, 2019 at 03:56:43PM +0200, Tim Düsterhus wrote:
> Luca,
>
> Am 10.09.19 um 15:48 schrieb Schimweg, Luca:
> > sorry,
On Tue, Sep 10, 2019 at 03:56:43PM +0200, Tim Düsterhus wrote:
> Luca,
>
> Am 10.09.19 um 15:48 schrieb Schimweg, Luca:
> > sorry, didn't know about these guidelines. I packed all changes into one
> > commit in the patch file in the attachments.
>
> One more thing: Do not leave out the body of
Luca,
Am 10.09.19 um 15:48 schrieb Schimweg, Luca:
> sorry, didn't know about these guidelines. I packed all changes into one
> commit in the patch file in the attachments.
One more thing: Do not leave out the body of the commit message. See the
paragraph starting line 562 of the CONTRIBUTING
Hey,
sorry, didn't know about these guidelines. I packed all changes into one commit
in the patch file in the attachments.
I included your changes, you are right, the code looks much better now.
I'm open for any feedback.
Best regards,
Luca
On 10.09.19, 14:25, "Tim Düsterhus" wrote:
Luca,
(not an HAProxy maintainer)
please have a look at the CONTRIBUTING file regarding the commit message
format: https://github.com/haproxy/haproxy/blob/master/CONTRIBUTING
You are missing the severity indicator and the affected subsystem. It
probably should be `MINOR: sample:`.
> diff --git
Hey,
I just integrated your change requests into my fork and created a PR:
https://github.com/haproxy/haproxy/pull/271, would be happy if anyone could
give me some feedback!
Best regards,
Luca
On 06.09.19, 11:41, "Willy Tarreau" wrote:
On Fri, Sep 06, 2019 at 11:33:32AM +0200, Geoff
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?
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
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
On Thu, Sep 05, 2019 at 05:13:11PM +, Schimweg, Luca wrote:
> Hey,
>
> just for you to get an impression, a quick draft of what a change could look
> like:
>
> https://github.com/lucaschimweg/haproxy/commit/5306395c062ac20b6d030d48c48290d5f08db5cc
( pasted here for discussion)
> char
Hi,
On Thu, Sep 05, 2019 at 05:31:36PM +0200, Lukas Tribus wrote:
> > unique-id-format
> >
Hey,
just for you to get an impression, a quick draft of what a change could look
like:
https://github.com/lucaschimweg/haproxy/commit/5306395c062ac20b6d030d48c48290d5f08db5cc
I didn't check with the contributing guidelines, etc... yet, but this commit
would make the feature work.
In the
Hello Luca,
On Thu, Sep 5, 2019 at 5:38 PM Schimweg, Luca wrote:
>
> Hey,
>
> i would suggest adding support for the widely used RFC4122 Version 4 UUID,
> which is generated completely random. In lua a script for generating these is
> about 5 lines long, but because of several reasons I don't
On 9/5/19 17:43, Schimweg, Luca wrote:
>
> actually, I am doing that, I generate a random number from 0-16383
> and after that I add 32768 onto it. 32768 is 0x8000,
> 32768+16383=49151 is 0xBFFF.
Ah, I missed it, sorry again.
Geoff
--
** * * UPLEX - Nils Goroll Systemoptimierung
Hey,
actually, I am doing that, I generate a random number from 0-16383 and after
that I add 32768 onto it. 32768 is 0x8000, 32768+16383=49151 is 0xBFFF. I
cannot really come up with a reason why this is too, but the specification is
fulfilled.
And yeah, we could definitely generate any other
Hey,
i would suggest adding support for the widely used RFC4122 Version 4 UUID,
which is generated completely random. In lua a script for generating these is
about 5 lines long, but because of several reasons I don't want to use lua in
this use-case.
I would definitely not add add additional
On 9/5/19 16:58, Schimweg, Luca wrote:
>
>
> unique-id-format
> %[rand,hex,bytes(8,8),lower]-%[rand(65536),hex,bytes(12,4),lower]-4%[rand(4096),hex,bytes(13,3),lower]-%[rand(16384),add(32768),hex,bytes(12,4),lower]-%[rand(65536),hex,bytes(12,4),lower]%[rand,hex,bytes(8,8),lower]
This is going
Hello,
On Thu, Sep 5, 2019 at 4:58 PM Schimweg, Luca wrote:
>
> Hey again,
>
> I tried to use rand, but when using it, my generation code for a UUID looks
> like this:
>
> unique-id-format
>
Hey again,
I tried to use rand, but when using it, my generation code for a UUID looks
like this:
unique-id-format
@formilux.org
Subject: Re: RFC uuid for log-format
Hi,
On Tue, 2019-09-03 at 14:07 +, Schimweg, Luca wrote:
> thanks for mentioning rand, I didn't know about it... With some
> rand()s I was able to generate a UUID, I'll have to do some
> performance checks, but I think it will be fair enough
Hi,
On Tue, 2019-09-03 at 14:07 +, Schimweg, Luca wrote:
> thanks for mentioning rand, I didn't know about it... With some
> rand()s I was able to generate a UUID, I'll have to do some
> performance checks, but I think it will be fair enough. Then we don't
> need a %uuid or similar from my
Hey,
thanks for mentioning rand, I didn't know about it... With some rand()s I was
able to generate a UUID, I'll have to do some performance checks, but I think
it will be fair enough. Then we don't need a %uuid or similar from my point of
view.
Thanks,
Luca
On 03.09.19, 10:34,
Hello Luca,
On Tue, 3 Sep 2019 at 09:18, Schimweg, Luca wrote:
>
> Hey,
>
>
>
> for one use case I have, I would need a variable like %uuid in log-formats,
> which just generates a random UUID. The use-case would be, to be able
> to set the unique-id-format to this uuid, so that we can have a
I would be open to implement this feature, as it is currently not possible to
implement this behavior (at least afaik). Would there be interest in such a
feature from the community?
From: "Schimweg, Luca"
Date: Tuesday, 3. September 2019 at 09:19
To: "haproxy@formilux.org"
Subject: [CAUTION]
35 matches
Mail list logo
