Is our Go uuid out of date? https://code.google.com/p/go-uuid/source/browse/uuid/version4.go is pulling random bits from crypto/rand - I don't see how we could be racing?

EDIT: Duh, not using .New. Maybe we should just be using that instead - I don't think we're benefiting from v1 UUID in any material way right now (unless we picked a backing store like mongo and wanted insertion order).

Well, we could switch to NewRandom() but then we'd run the risk of collisions, so we'd be forced to go to etcd to check (and without indices, that's going to be expensive, and even with indices, its not great)

So version1 UUID enables us be sure that they're unique (assuming that we don't give them out to quickly) hence this PR.

I think this is actually a pretty decent solution, given that most of the time, we won't have to wait.

Given the rate of uuid generation (and hence locks and goroutine creation here) is unlikely to be the dominant factor, that's fine with me.

Puke. Are we really concerned about UUID collisions in a single resource
type? Can't we just use random and +1 the indices bug?

On Sun, Nov 2, 2014 at 2:14 PM, Clayton Coleman [email protected]
wrote:

Given the rate of uuid generation (and hence locks and goroutine creation
here) is unlikely to be the dominant factor, that's fine with me.

Reply to this email directly or view it on GitHub
#2120 (comment)
.

imho, UUID collisions via Random are worse than the current (buggy) state. At least this is predictably reproducible. Random collisions will just lead to occasionally random behavior.

I really, really, really, don't want to have to go to the data store ever time to make sure that I don't have the same UUID already in use. This is ugly, but I think a reasonable solution.

--brendan

wat. This is the single purpose of a UUID. This PR should not be needed. Is there another UUID package we can use?

I think a random UUID should be sufficient for the moment. 1/trillions chance of collision is low enough that we don't need to check. (Not that we could check at the moment, anyway, without an index.)

Long term, better than either of these solutions, is to just assign each running master a UID prefix, and then they can just count up to make globally unique UIDs.

This isn't a problem with the package, its a problem with the choice of
uuid algorithm. We are currently using version #1 which encodes time at
the 100 nanosecond granularity.

We could go to random, but why? Why implement a known buggy solution
because you have aesthetic objections?

Brendan
On Nov 3, 2014 10:16 AM, "Daniel Smith" [email protected] wrote:

wat. This is the single purpose of a UUID. This PR should not be needed.
Is there another UUID package we can use?

I think a random UUID should be sufficient for the moment. 1/trillions
chance of collision is low enough that we don't need to check. (Not that we
could check at the moment, anyway, without an index.)

Long term, better than either of these solutions, is to just assign each
running master a UID prefix, and then they can just count up to make
globally unique UIDs.

—
Reply to this email directly or view it on GitHub
#2120 (comment)
.

+1 to not going to etcd to check for collisions.

I like time-based solutions. This could be optimized in the future to allow bursting by saving up a buffer of valid unused uuids.

It does mean that we may need to emphasize the importance of synchronizing clocks, however. (e.g., recommending time sync tests to run)

Also on the table is switching to Docker-style uids (#1944).

This seems good enough for now, though.

Ah, yes, I should have mentioned that. The correct approach is to store up old unused UUID tokens so that we don't have to ever actually wait, I'll add a TODO to do that.

I think the odds of a random collision are infinitesimal, to the degree
that checking for collisions could be done later, when we have an index,
and I bet a paycheck it would never be a problem.

But this is fine. It's just sort of vulgar to me, but it's not going to
actually affect anything as long as it is well documented.

On Mon, Nov 3, 2014 at 1:28 PM, Brendan Burns [email protected]
wrote:

Ah, yes, I should have mentioned that. The correct approach is to store up
old unused UUID tokens so that we don't have to ever actually wait, I'll
add a TODO to do that.

Reply to this email directly or view it on GitHub
#2120 (comment)
.