Open Stack

	OK, time for everyone to step back and take a deep breath.

	There are many implications of the earlier design decision to use integer PKs for database entries. Most who have responded here, myself included, have indicated that they would prefer that this be changed to either a string value comprised of several meaningful bits of information, or a UUID approach, or some combination of things that would address various things in the operation of a zoned design. I think that this will make an excellent discussion at next month's design summit!

	But the reality is that this needs to be developed now, under the current design of integer PKs. Please note that the only concern here is how to reconcile the Rackspace API requirement of globally unique instance IDs with the current design of generating PKs in local databases at the compute node level. To my understanding, there is no other alternative than partitioning the available integer range across zones, so that each zone generates its instance PKs starting from a different number, and spaced far enough apart that they will never overlap.

	In the first post of this thread, I proposed a simple partitioning system: allocating a range of integers for each zone, and asked for feedback as to what people would think would be a reasonable estimate for the maximum number of instances a zone would ever need to create. Most shared my distaste for this sort of partitioning system, but no one offered an alternative that would be workable given the current constraints. So I'm going to implement a partition of 1 billion integers per zone, which should allow for approximately 1 billion zones, given a 64 bit integer for the PK. This should be workable for now, and after the design summit, when we've come to a consensus on changing the API to accept something other than integer identifiers, it should not be too difficult to retrofit.

	Unless someone has a better idea... ;-)


-- Ed Leafe