Totally agree with Eric.<div><div><br></div><div>Two questions that I think can help us move forward:</div><div><br></div><div><ol><li>Is the decision to stick with integers still valid?  Can someone that was there give us the reason for the decision?  Is it documented anywhere?</li>
<li>If "we must have integers" means that we get 128 bit 'random' integers, do we still want integers?</li></ol></div><div><br></div><div><br></div>Justin<br><br><br><br>
<br><br><div class="gmail_quote">On Tue, Mar 22, 2011 at 11:25 AM, Eric Day <span dir="ltr"><<a href="mailto:eday@oddments.org">eday@oddments.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, Mar 22, 2011 at 12:40:21PM -0400, Ed Leafe wrote:<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>
</div>We shouldn't dismiss previous ideas just because we've not chosen<br>
them in the past, but lets not have the same discussion.<br>
<div class="im"><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>
</div>I think we need:<br>
<br>
* No central authority such as a globally shared DB. This also<br>
  means not partitioning some set and handing them out to zones as<br>
  offset (this is just another form of a shared DB).<br>
<br>
* Ability to seamlessly join existing zones without chance of namespace<br>
  collisions for peering and bursting. This means a globally unique<br>
  zone naming scheme, and for this I'll reiterate the idea of using<br>
  DNS names for zones.<br>
<br>
If we want to stick with a single DB per zone, as it looks like we<br>
are, this can simply be the auto-increment value from the instance<br>
table and the zone as: <instance>.<zone>.<br>
<div class="im"><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>
</div>I'm not concerned with aesthetic issues to be honest. We have<br>
copy/paste, DNS, and various techniques for presentation layers.<br>
<font color="#888888"><br>
-Eric<br>
</font><div><div></div><div class="h5"><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>
</div></div></blockquote></div><br></div>