Generate a time-based (V1) UUID instead of random (V4)

[afcollins]

UUIDs are defined by RFC 4122, and there are 4 variants. We currently generate a random UUID, which is variant 4.

The library we use (satori/go.uuid) does expose a V1 variant.

The benefit is that generating new UUIDs as V1, they become self-ordering. So, when I open our Grafana dashboard to a date range and want to look at the runs over a time interval, I can know which runs happened in order without the mapping overhead of locating the kube-burner output logs (if I even have access to them).

The UUIDs generated from e2e have the date in them, which is helpful. But if I am running outside of e2e-benchmarking or from a local client, this is a small quality of life improvement.

[smalleni]

@rsevilla87 @vishnuchalla Looks like you may have missed this idea - thoughts

[rsevilla87]

oh this is interesting, tbh, I didn't know there was a UUID version based on timestamp, we can easily switch it

[rsevilla87]

Did some quick tests

$ cat main.go 
package main

import (
        "fmt"

        uid "github.com/satori/uuid"
)

func main() {
        fmt.Println(uid.NewV1().String())
        fmt.Println(uid.NewV4().String())
}
rsevilla@wonderland /tmp/uuid $ go run main.go 
6bc12a47-8206-11ee-905b-f426798329f8
4207ab90-0c70-4b0b-9600-ed49083fdae0
rsevilla@wonderland /tmp/uuid $ go run main.go 
6c3a0d31-8206-11ee-9a91-f426798329f8
6f98ce3f-f6a1-4b49-9286-7a0d545aa77b
rsevilla@wonderland /tmp/uuid $  go run main.go  # After waiting for some time
01d4d892-820b-11ee-8842-f426798329f8
6209b425-5038-4183-9caf-7e1831344b5a

[rsevilla87]

It seems like the two first group of characters is time based, however, the second group got increased after the first group, (that wont allow us th sort them alphabetically), have to read the RFC deeper though

[afcollins]

Hmm. My misunderstanding then. I thought I ran a test and saw them in a sortable format before I posted this.

So, they won't alphabetically sortable.

[afcollins]

I see ULIDs are an attempt to solve the sortable problem.
https://github.com/ulid/spec?tab=readme-ov-file

However, the cost of that migration for existing data would likely be prohibitive.