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