oops ids aren't very unique

[Brian Murray]

Looking at this bucket we can see that there isn't much variation among the Oops ids - https://errors.ubuntu.com/bucket/?id=/usr/lib/ubiquity/bin/ubiquity:ValueError:watch_debconf_fd_helper:process_input:wait:cleanup:preseed:%3Clambda%3E:command.

The 3rd and the 5th fields seem to repeat a lot and only have 2 variations. I believe it is because of the following:

    user_token = None
    # / + 128 character system UUID
    if len(environ['PATH_INFO']) == 129:
        user_token = environ['PATH_INFO'][1:]

    oops_id = str(uuid.uuid1())

I believe there are only two servers accepting errors and this would explain the lack of variation.

[Brian Murray (brian-murray)]

To be clear I'd expected the user_token to be used as a part of generating the oops_id.

[Evan (ev)]

Yes, because version 1 UUIDs use the MAC address to form part of the hash, we will only have the two variations, one for each of the Apache frontends serving daisy.ubuntu.com.

While Cassandra's TimeUUIDs only map to version 1 UUIDs, we are not yet using them for sorting. I had planned to, as I consider the current lexicographic sorting of error reports on the problem page to be a bug. I had envisioned a time-sorted and paginated view of all the instances of the problem. However, we could do something similar to the DayOOPS column family, where the column name is a TimeUUID type and the value is the OOPS ID.

Alternatively, we could find a way to hash the user_token field to fit the MAC address field, as you suggest.

I guess the next step would be to calculate how quickly we'll run out of version one UUIDs given the lack of variation on the MAC address.

[Evan (ev)]

There's also https://github.com/twitter/snowflake

[Evan (ev)]

uuid1() is guaranteed to not produce any collisions:
http://stackoverflow.com/questions/703035/when-are-you-truly-forced-to-use-uuid-as-part-of-the-design/786541#786541