<div>I think _if_ we want to stick with straight numbers, the following are the 'traditional' choices:</div><div><br>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.</div>
<div>2) Prefixing - so zone0 would get 0xxxxxxx, zone1 1xxxxxx.</div><div>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.</div>
<div>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.</div><div><br></div><div>(If you want central allocation without a shared database, that's also possible, but requires some trickier protocols.)</div>
<div><br></div><div>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!</div>
<div><br></div><div>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...</div><div><br></div>
<div>Justin</div><div><br>
<br><br><div class="gmail_quote">On Tue, Mar 22, 2011 at 9:40 AM, Ed Leafe <span dir="ltr"><<a href="mailto:ed@leafe.com">ed@leafe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
        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.<br>

<br>
        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.<br>

<br>
        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.<br>

<br>
        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.<br>

<br>
<br>
<br>
-- Ed Leafe<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</blockquote></div><br></div>