If I had to choose between dropping or truncating UUIDs and failing feature parity with the ec2 api, i'd go with the latter. Pros and cons for UUIDs have already been discussed and decisions made. The EC2 api shouldn't get in the way. A translation layer to sit in between the EC2 and OS APIs would solve this issue without revisiting the UUID argument.<div>
<br></div><div><br><br><div class="gmail_quote">On Thu, Jul 7, 2011 at 9:57 AM, Soren Hansen <span dir="ltr"><<a href="mailto:soren@linux2go.dk">soren@linux2go.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2011/7/7 Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>>:<br>
<div class="im">> Multiple zones is currently only supported in the OpenStack API, and<br>
> the question has been raised whether effort should be expended to get<br>
> parity in the EC2 API for this. The problem with the EC2 API is that<br>
> we do not have control over the instance identifiers -- they are an 8<br>
> character text string. We would still need to map the EC2 instance<br>
> identifier to some globally unique identifier (like a UUID), but the<br>
> solutions for how to do this aren't pretty (see<br>
> <a href="http://etherpad.openstack.org/EC2UUID" target="_blank">http://etherpad.openstack.org/EC2UUID</a>).<br>
<br>
</div>I don't particularly like the idea of maintaining a mapping table. If<br>
such a method is to be guaranteed to function, we need something that<br>
can reliably assign EC2-compatible ID's corresponding to the UUID's<br>
without collisions. If we can come up with such a method anyway, why<br>
use UUID's to begin with?<br>
<br>
(For the record, I do believe we *can* come up with such a method. I<br>
raised this point in one of the (several) disucssions we've had on the<br>
subject of ID's, but the ability to assign an unlimited amount of<br>
non-colliding ID's perpetually autonomously took precedence)<br>
<br>
I think the only sensible route is truncating (or by other means<br>
reducing) the UUIDs to 32 bits (or revisit (again) the choice of<br>
UUID's, of course).<br>
With a 32 bit key space, a user with 10000 active objects of the same<br>
type (so in the same key space) will have a 1% chance of having<br>
colliding ID's. With ~78000 objects, we're at 50%. I guess that's a<br>
risk we'll have to live with. The tricky part is figuring out how to<br>
handle the collisions when they actually arise.<br>
<font color="#888888"><br>
--<br>
Soren Hansen        | <a href="http://linux2go.dk/" target="_blank">http://linux2go.dk/</a><br>
Ubuntu Developer    | <a href="http://www.ubuntu.com/" target="_blank">http://www.ubuntu.com/</a><br>
OpenStack Developer | <a href="http://www.openstack.org/" target="_blank">http://www.openstack.org/</a><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>