I think _if_ we want to stick with straight numbers, the following are the 'traditional' choices:
1) "Skipping" - so zone1 would allocate numbers 1,3,5, zone2 numbers 2,4,6. Requires that you know in advance how many zones there are. 2) Prefixing - so zone0 would get 0xxxxxxx, zone1 1xxxxxx. 3) Central allocation - each zone would request an ID from a central pool. This might not be a bad thing, if you do want to have a quick lookup table of ID -> zone. Doesn't work if the zones aren't under the same administrative control. 4) Block allocation - a refinement of #3, where you get a bunch of IDs. Effectively amortizes the cost of the RPC. Probably not worth the effort here. (If you want central allocation without a shared database, that's also possible, but requires some trickier protocols.) However, I agree with Monsyne: numeric IDs have got to go. Suppose I'm a customer of Rackspace CloudServers once it is running on OpenStack, and I also have a private cloud that the new Rackspace Cloud Business unit has built for me. I like both, and then I want to do cloud bursting in between them, by putting an aggregating zone in front of them. I think at that stage, we're screwed unless we figure this out now. And this scenario only has one provider (Rackspace) involved! We can square the circle however - if we want numbers, let's use UUIDs - they're 128 bit numbers, and won't in practice collide. I'd still prefer strings though... Justin On Tue, Mar 22, 2011 at 9:40 AM, Ed Leafe <[email protected]> wrote: > 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 : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
