I'd like to point out that while I agree with moving to strings (and using UUIDs as internal identifiers), this is a discussion for the summit, and under no circumstances should anyone get the impression that a change to the identifier will be occurring for Cactus!
-jay On Tue, Mar 22, 2011 at 4:06 PM, Justin Santa Barbara <[email protected]> wrote: > Let's take a leadership position here and go with strings; we're not > breaking Amazon's API. AWS will have to make the same changes when they > reach our scale and ambition :-) > We should also start engaging with client tools, because we're never going > to be 100% EC2 compatible. At the least, our endpoints will be different. > I think we should discuss this at the Design Summit, and then make an effort > on this front as part of Diablo. > > > On Tue, Mar 22, 2011 at 12:58 PM, Vishvananda Ishaya <[email protected]> > wrote: >> >> Yes, that is what they say, Unfortunately all of the ec2 tools expect the >> current format that they are using to various degrees. >> Some just need the proper prefix (euca2ools) >> Others need the prefix + hex (elasticfox, irrc) >> Others allow a string but limit it to 11 chars, etc. >> So to keep compatibility we are stuck mimicking amazon's string version >> for now. >> Vish >> On Mar 22, 2011, at 12:51 PM, Justin Santa Barbara wrote: >> >> 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 > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
