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.
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.