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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
