Hi, 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 them. Willy