I think Dragon got it right. We need a zone identifier prefix on the IDs. I think we need to get away from numbers. I don't see any reason why they need to be numbers. But, even if they did, you can pick very large numbers and reserve some bits for zone ID.
- Chris On Mar 22, 2011, at 10:48 AM, Justin Santa Barbara wrote: > 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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
