EC2 uses xsd:string for their instance id. I can't find any additional guarantees.
Here's a (second hand) quote from Amazon: http://serverfault.com/questions/58401/is-the-amazon-ec2-instance-id-unique-forever "Instance ids are unique. You'll never receive a duplicate id. However, the current format of the instance id is an implementation detail that is subject to change. If you use the instance id as a string, you should be fine." So, strings it is then? :-) On Tue, Mar 22, 2011 at 12:44 PM, Vishvananda Ishaya <[email protected]>wrote: > The main issue that drove integers is backwards compatibility to the > ec2_api and existing ec2 toolsets. People seemed very opposed to the idea > of having two separate ids in the database, one for ec2 and one for the > underlying system. If we want to move to another id scheme that doesn't fit > in a 32 bit integer we have to provide a way for ec2 style ids to be > assigned to instances, perhaps through a central authority that hands out > unique ids. > > Vish > > On Mar 22, 2011, at 12:30 PM, Justin Santa Barbara wrote: > > The API spec doesn't seem to preclude us from doing a fully-synchronous > method if we want to (it just reserves the option to do an async > implementation). Obviously we should make scheduling fast, but I think > we're fine doing synchronous scheduling. It's still probably going to be > much faster than CloudServers on a bad day anyway :-) > > Anyone have a link to where we chose to go with integer IDs? I'd like to > understand why, because presumably we had a good reason. > > However, if we don't have documentation of the decision, then I vote that > it never happened, and instance ids are strings. We've always been at war > with Eastasia, and all ids have always been strings. > > Justin > > > > > On Tue, Mar 22, 2011 at 12:20 PM, Paul Voccio > <[email protected]>wrote: > >> I agree with the sentiment that integers aren't the way to go long term. >> The current spec of the api does introduce some interesting problems to >> this discussion. All can be solved. The spec calls for the api to return >> an id and a password upon instance creation. This means the api isn't >> asynchronous if it has to wait for the zone to create the id. From page 46 >> of the API Spec states the following: >> >> "Note that when creating a server only the server ID and the admin >> password are guaranteed to be returned in the request object. Additional >> attributes may be retrieved by performing subsequent GETs on the server." >> >> >> >> This creates a problem with the bursting if Z1 calls to Z2, which is a >> public cloud, which has to wait for Z3-X to find out where it is going be >> placed. How would this work? >> >> pvo >> >> On 3/22/11 1:39 PM, "Chris Behrens" <[email protected]> wrote: >> >> > >> >I think Dragon got it right. We need a zone identifier prefix on the >> >IDs. I think we need to get away from numbers. I don't see any reason >> >why they need to be numbers. But, even if they did, you can pick very >> >large numbers and reserve some bits for zone ID. >> > >> >- Chris >> > >> > >> >On Mar 22, 2011, at 10:48 AM, Justin Santa Barbara wrote: >> > >> >> I think _if_ we want to stick with straight numbers, the following are >> >>the 'traditional' choices: >> >> >> >> 1) "Skipping" - so zone1 would allocate numbers 1,3,5, zone2 numbers >> >>2,4,6. Requires that you know in advance how many zones there are. >> >> 2) Prefixing - so zone0 would get 0xxxxxxx, zone1 1xxxxxx. >> >> 3) Central allocation - each zone would request an ID from a central >> >>pool. This might not be a bad thing, if you do want to have a quick >> >>lookup table of ID -> zone. Doesn't work if the zones aren't under the >> >>same administrative control. >> >> 4) Block allocation - a refinement of #3, where you get a bunch of IDs. >> >> Effectively amortizes the cost of the RPC. Probably not worth the >> >>effort here. >> >> >> >> (If you want central allocation without a shared database, that's also >> >>possible, but requires some trickier protocols.) >> >> >> >> However, I agree with Monsyne: numeric IDs have got to go. Suppose I'm >> >>a customer of Rackspace CloudServers once it is running on OpenStack, >> >>and I also have a private cloud that the new Rackspace Cloud Business >> >>unit has built for me. I like both, and then I want to do cloud >> >>bursting in between them, by putting an aggregating zone in front of >> >>them. I think at that stage, we're screwed unless we figure this out >> >>now. And this scenario only has one provider (Rackspace) involved! >> >> >> >> We can square the circle however - if we want numbers, let's use UUIDs >> >>- they're 128 bit numbers, and won't in practice collide. I'd still >> >>prefer strings though... >> >> >> >> Justin >> >> >> >> >> >> >> >> On Tue, Mar 22, 2011 at 9:40 AM, Ed Leafe <[email protected]> wrote: >> >> I want to get some input from all of you on what you think is >> >>the best way to approach this problem: the RS API requires that every >> >>instance have a unique ID, and we are currently creating these IDs by >> >>use of an auto-increment field in the instances table. The introduction >> >>of zones complicates this, as each zone has its own database. >> >> >> >> The two obvious solutions are a) a single, shared database and >> >>b) using a UUID instead of an integer for the ID. Both of these >> >>approaches have been discussed and rejected, so let's not bring them >> >>back up now. >> >> >> >> Given integer IDs and separate databases, the only obvious >> >>choice is partitioning the numeric space so that each zone starts its >> >>auto-incrementing at a different point, with enough room between >> >>starting ranges to ensure that they would never overlap. This would >> >>require some assumptions be made about the maximum number of instances >> >>that would ever be created in a single zone in order to determine how >> >>much numeric space that zone would need. I'm looking to get some >> >>feedback on what would seem to be reasonable guesses to these partition >> >>sizes. >> >> >> >> The other concern is more aesthetic than technical: we can make >> >>the numeric spaces big enough to avoid overlap, but then we'll have very >> >>large ID values; e.g., 10 or more digits for an instance. Computers >> >>won't care, but people might, so I thought I'd at least bring up this >> >>potential objection. >> >> >> >> >> >> >> >> -- Ed Leafe >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Mailing list: https://launchpad.net/~openstack >> >> Post to : [email protected] >> >> Unsubscribe : https://launchpad.net/~openstack >> >> More help : https://help.launchpad.net/ListHelp >> >> >> >> _______________________________________________ >> >> Mailing list: https://launchpad.net/~openstack >> >> Post to : [email protected] >> >> Unsubscribe : https://launchpad.net/~openstack >> >> More help : https://help.launchpad.net/ListHelp >> > >> > >> >_______________________________________________ >> >Mailing list: https://launchpad.net/~openstack >> >Post to : [email protected] >> >Unsubscribe : https://launchpad.net/~openstack >> >More help : https://help.launchpad.net/ListHelp >> >> > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
