openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

Hi Ed,

May I ask what is the point of doing this if it won't make cactus and
we're just going to replace it in a month or two? I think we all agree
that 64-bit integer IDs are insufficient for multi-zone deployments,
so no one will be deploying this until we sort it out and come up
with a better ID.

Since we've reached MP freeze, and none of this is going to make it
into cactus, it seems to make the most sense to finish flushing this
out on the ML (I think we're close), discuss at the summit if needed,
and implement it once we have a consensus on a more robust solution.

-Eric

On Wed, Mar 23, 2011 at 08:24:29PM -0400, Ed Leafe wrote:
> 	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
> 
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp