> 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
