Open Stack

On Jul 11, 2011, at 11:28 AM, Eric Day wrote:

>> This is only a real problem if you insist on generating them in real
>> time rather than pre-allocate them. Each compute node could have pool
>> of thousands of ID's it could use as it pleased. That would still
>> allow for millions of compute nodes. The ID's could be centrally
>> assigned. Even if the central component that hands them out goes away,
>> a couple of thousand ID's should provide ample time for a replacement
>> to be spun up (or for the original one to come back).
> 
> This assumes you still have something you can call "central". What
> about hybrid or peer-to-peer clouds? Does each zone get assigned a
> ID allocator service? Each account? What if it is behind a firewall
> but I have public cloud bursting and don't want to open it up?

	The notion of a partitioning of potential IDs was considered and rejected in favor of using UUIDs. The notion of a central repository was considered and rejected in favor of a 'shared nothing' approach to distributed zones. I'd like to keep this discussion focused on moving from where we are today to where we'd like to be.

	Right now we have UUIDs as the primary key for instances, as well as sequential integer IDs that are unique within a zone. The code base was changed to only use UUIDs at inter-zone boundaries, and preserve the practice of basing the EC2 ID on the instance's integer ID, effectively relegating EC2 to single-zone deployments only.

	The only question that needs to be considered is where do we move from here? Do we accept the limitation that the EC2 API and any tool which relies upon that will be only available for single-zone deployments, and if you want distributed zones, you must use the OS API? Or do we reconsider the hybrid UUID/integer zone design, and move to a full UUID design?

	If we decide to move to a full UUID design with EC2 API as a first-class citizen, then we have the question of how to represent the 32-character UUID in the 8-character EC2 ID format. Our choices there are:

1) Use the full 32 chars, and let the tools that assume 8 chars break.
2) Use the first 8 chars, and accept an occasional duplicate ID.
3) Use the first 8 chars, but add duplication checking.


-- Ed Leafe

This email may include confidential information. If you received it in error, please delete it.