Seems resonable +1 to design summit discussion
Vish On Mar 22, 2011, at 1:06 PM, Justin Santa Barbara 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 <vishvana...@gmail.com> > 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 <vishvana...@gmail.com> >> 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 <paul.voc...@rackspace.com> >>> 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" <chris.behr...@rackspace.com> 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 <e...@leafe.com> 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 : openstack@lists.launchpad.net >>> >> Unsubscribe : https://launchpad.net/~openstack >>> >> More help : https://help.launchpad.net/ListHelp >>> >> >>> >> _______________________________________________ >>> >> Mailing list: https://launchpad.net/~openstack >>> >> Post to : openstack@lists.launchpad.net >>> >> Unsubscribe : https://launchpad.net/~openstack >>> >> More help : https://help.launchpad.net/ListHelp >>> > >>> > >>> >_______________________________________________ >>> >Mailing list: https://launchpad.net/~openstack >>> >Post to : openstack@lists.launchpad.net >>> >Unsubscribe : https://launchpad.net/~openstack >>> >More help : https://help.launchpad.net/ListHelp >>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~openstack >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~openstack >>> More help : https://help.launchpad.net/ListHelp >> >> > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
