Daisy

oops ids aren't very unique

Bug #1032398 reported by Brian Murray on 2012-08-02

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	Daisy	Confirmed	High	Unassigned

Bug Description

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.

Revision history for this message

Brian Murray (brian-murray) wrote on 2012-08-02:

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

Revision history for this message

Evan (ev) wrote on 2012-08-11:

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.