First, y'all need to remember that it isn't just AWS... it's N systems that back-end OS API over time.
Ewan, I understand your intent, but it is a bit myopic: 1) Done right, the only time I need native IDs is when I have a complex situation which needs debugging. It isn't the norm (or if it is, we've failed) -- so really I ONLY need native IDs when it's all gone pear shaped. 2) Multi-API integration is (see point above) a secondary or tertiary set of use cases. Consider using discovery pattern for those integrations rather than trying to shove them as primary into the OS interfaces... which will only end in maddening disaster after you add more than AWS in terms of required support. A general pattern for native discovery in these exception cases needs to be the focus. 3) We fail if we put native debugging capability in front of properly architected and designed OS API semantics 4) Performance benefits? You need to convince me the transaction rate capability is seriously impacted on string vs guid implementations. Sorry, but doubtful. (mea culpa: I am not familiar with implementation details of this context but still..) Look, as an API user... frankly, I don't want to manage complexity across providers. The more OS can insulate me from the details while providing equivalent functionality the better. And quickly, please. I'm rather interested in betting a whole company on an API that groks that value equals maximum insulation from native platforms while giving me 80% plus of capabilities across all native platforms... and APIs to support exploration and integration for the 20% that I invest in. We all need to get out of reactive, myopic, API-to-API-parity mode and into OpenStack centric API capability mode. OpenStack will win on ubiquity of cloud capability not on API/feature parity with whomever is out there. This is my final post on this topic here. I'll be focusing on other topics but I'm glad this gave the opportunity to share the perspective I have and I very much desire further conversation along any dimension at jan_dr...@hotmail.com. I'd value key architects for OS reaching out to me on this and other topics. Jan Drake > From: ewan.mel...@eu.citrix.com > To: devin.car...@gmail.com; so...@linux2go.dk > Date: Mon, 11 Jul 2011 06:43:32 +0100 > CC: chris.behr...@rackspace.com; ed.le...@rackspace.com; > openstack@lists.launchpad.net > Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is > it worth the effort? > > > From: Devin Carlen > > > > Here's a few crazy questions for you guys to consider: > > > > 1) Why are we even trying to have the same ID for an instance or image > > across two different APIs? > > To reduce complexity (particularly when trying to debug the system as a > whole). > > > 2) How many people really switch back and forth between OpenStack and > > EC2 API once they pick one? > > This will be very common. We're going to have UIs that use the OpenStack > API, monitoring systems that use the EC2 API, CLIs using either, all in use > on the same cloud, by the same users, at the same time. > > Also, the multi-zone support is built using the OpenStack API, and the > Quantum integration will no doubt use it too, so in reality any use of the > EC2 API at all is going to give us a multi-API cloud. > > > 3) How many people really expect euca2ools and python-novatools to > > return the same IDs for the same instances? > > It sure would make it a lot easier to debug! > > > 4) Why not just store a EC2 ID and a OS ID alongside an actual row PK? > > > > My point with these questions is that very little is gained from > > forcing two different APIs to try to use the same ID, especially given > > that the format is different. I would argue that it has created a lot > > more problems than it has solved. > > This is certainly a possibility. The problem with this is you have to do the > central allocation for the EC2 ID, so you destroy the performance benefits of > using a UUID. > > I could imagine a scheme where the EC2 ID was lazily generated, so you didn't > allocate one unless that API was used. That would meet all of _my_ > requirements, I think (I'm not sure about anyone else's). The downside with > that is it's more complicated, of course. > > Ewan. > > > > > > > > Devin > > > > > > > > On Jul 8, 2011, at 3:12 PM, Soren Hansen wrote: > > > > > 2011/7/8 Vishvananda Ishaya <vishvana...@gmail.com>: > > >> Yes they seem to apply to all ids > > >> r-XXXXXXX > > >> ami-XXXXXXX > > >> i-XXXXXXX > > >> vol-XXXXXXX > > >> snap-XXXXXXX > > >> > > >> That said we are using base-36 for the hex in reservation ids and no > > one has complained, so i don't think they are used by the tools that > > much. > > > > > > Not true. ElasticFox does not work with this. > > > > > > I don't think we're yet at a point where we can say that lack of > > > complaints about stuff means something's fine. That sort of > > assumption > > > only starts to be useful when we have lots of real users. The users > > we > > > have so far are people who care about OpenStack for OpenStack's sake, > > > not "random" users who are being given access to an OpenStack > > > deployment and being told "talk to this like you would talk to EC2. > > > It'll work fine." Different expectations. > > > > > > -- > > > Soren Hansen | http://linux2go.dk/ > > > Ubuntu Developer | http://www.ubuntu.com/ > > > OpenStack Developer | http://www.openstack.org/ > > > > > > _______________________________________________ > > > 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
