I want to get some input from all of you on what you think is the best
way to approach this problem: the RS API requires that every instance have a
unique ID, and we are currently creating these IDs by use of an auto-increment
field in the instances table. The introduction of zones complicates this, as
each zone has its own database.
The two obvious solutions are a) a single, shared database and b) using
a UUID instead of an integer for the ID. Both of these approaches have been
discussed and rejected, so let's not bring them back up now.
Given integer IDs and separate databases, the only obvious choice is
partitioning the numeric space so that each zone starts its auto-incrementing
at a different point, with enough room between starting ranges to ensure that
they would never overlap. This would require some assumptions be made about the
maximum number of instances that would ever be created in a single zone in
order to determine how much numeric space that zone would need. I'm looking to
get some feedback on what would seem to be reasonable guesses to these
partition sizes.
The other concern is more aesthetic than technical: we can make the
numeric spaces big enough to avoid overlap, but then we'll have very large ID
values; e.g., 10 or more digits for an instance. Computers won't care, but
people might, so I thought I'd at least bring up this potential objection.
-- 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
