openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

Yes the issue isn't the actual api definition, the issue is that most of the ec2 clients expect the exact format that amazon currently uses ami-<8 hex chars>.

I think we should move toward ec2 being a compatibility layer that is translated into the os api.  This compatibility layer would sit at the top level zone and could maintain its own database for conversion of ids, management of secret and access keys, etc.



On Jul 7, 2011, at 8:05 AM, Thorsten von Eicken wrote:

> 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.
>> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp