openstack team mailing list archive

[Thorsten von Eicken <tve@xxxxxxxxxxxxxx>]

FYI, there's nothing in the EC2 API that limits instance identifiers (or
other IDs) to 32 bits. The IDs are strings, so it's trivial for EC2 to
add another digit when running out of 32-bit IDs.
    TvE

On 7/7/2011 7:57 AM, Soren Hansen wrote:
> 2011/7/7 Jay Pipes <jaypipes@xxxxxxxxx>:
>> Multiple zones is currently only supported in the OpenStack API, and
>> the question has been raised whether effort should be expended to get
>> parity in the EC2 API for this. The problem with the EC2 API is that
>> we do not have control over the instance identifiers -- they are an 8
>> character text string. We would still need to map the EC2 instance
>> identifier to some globally unique identifier (like a UUID), but the
>> solutions for how to do this aren't pretty (see
>> http://etherpad.openstack.org/EC2UUID).
> I don't particularly like the idea of maintaining a mapping table. If
> such a method is to be guaranteed to function, we need something that
> can reliably assign EC2-compatible ID's corresponding to the UUID's
> without collisions. If we can come up with such a method anyway, why
> use UUID's to begin with?
>
> (For the record, I do believe we *can* come up with such a method. I
> raised this point in one of the (several) disucssions we've had on the
> subject of ID's, but the ability to assign an unlimited amount of
> non-colliding ID's perpetually autonomously took precedence)
>
> I think the only sensible route is truncating (or by other means
> reducing) the UUIDs to 32 bits (or revisit (again) the choice of
> UUID's, of course).
> With a 32 bit key space, a user with 10000 active objects of the same
> type (so in the same key space) will have a 1% chance of having
> colliding ID's. With ~78000 objects, we're at 50%. I guess that's a
> risk we'll have to live with. The tricky part is figuring out how to
> handle the collisions when they actually arise.
>