On Thu, Sep 05, 2019 at 05:31:36PM +0200, Lukas Tribus 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]
> >
> > To be honest I think for a simple UUID, we should not be required to but 
> > such a complicated and long line into the config. Also, I think that the 
> > performance impact of such a line is much bigger than the generation of a 
> > UUID in plain C code. We could just create a ACL generator called uuid or 
> > something similar which would do the job. The config would get much clearer.
> >
> > Any opinions to this? I would be willing to implement such a feature if the 
> > maintainers would be ready to merge it in general.
> Are you proposing to implement a RFC4122 compliant UUID?
> Which UUID version?
> Which dependencies would it require?
> I guess something RFC4122 compliant based on openssl for example would
> work. Adding chunks of fragile code nobody is gonna maintain or adding
> additional dependencies like libuuid - probably not.
> I suggest we wait for Willy's feedback, but I want to stress that this
> may not be as simple as 5 lines of standalone C code ... we certainly
> don't want to act like we are generating standard compliant RFC4122
> UUIDs when that is not really the case.

I've not looked at what RFC4122 suggests, but what I can tell is that
we'll get as many UUID formats as there are users anyway. If *some*
formats are standard and cover most people's needs, they are more
likely to be well adopted and we could imagine having a sample fetch
function to produce them more easily. But only if we really think it's
likely that they'll be used. In my experience, people dealing with
logs do *want* to integrate some elements helping with troubleshooting,
like a node name/number, a location in the chain, and sometimes some
timestamps because that helps keeping events ordered when processing


Reply via email to