This ship may have sailed, but given what I have seen across a wide variety of cloud APIs and what I are here, I strongly question the value of supporting an EC2 API. I think you overestimate the value of supporting existing tools.
Sent from my iPhone On Jul 8, 2011, at 19:32, Lorin Hochstein <lo...@isi.edu> wrote: > Stepping back for a moment, I think the two main benefits of supporting the > EC2 API are: > > - Leverage existing 3rd party tools that talk to EC2 API (e.g., euca2ools, > boto, Elasticfox/Hybridfox) > - Reduce the cost of switching to OpenStack for EC2 users > > I agree with Soren that these benefits are lost if OpenStack supports the > official EC2 spec but breaks compatibility with the existing tools and > scripts people already have. Better to not have an EC2 API at all than to > lose new users because they think OpenStack is "broken" when their EC2-based > tool fails to work. > > While the comparison with Wine is apt, I think an even more relevant > comparison would be Microsoft trying to stay compatible with third party > applications that worked on previous versions of Windows, even ones that > broke the API but still worked (See Raymon Chen's excellent "The Old New > Thing" blog for the Herculean efforts that MS developers had to put in to > accomplish this http://blogs.msdn.com/b/oldnewthing/). > > I don't think that the OpenStack project should commit to maintaining EC2 > compatibility at all costs, only as long as the benefits outweigh the > development costs. In particular, if Amazon deliberately started making > changes to break the API, that would be a good time to consider dropping > support. > > > Lorin > -- > Lorin Hochstein, Computer Scientist > USC Information Sciences Institute > 703.812.3710 > http://www.east.isi.edu/~lorin > > On Jul 8, 2011, at 6:59 PM, Jorge Williams wrote: > >> HTTP, SMTP, and IMAP and even ANSI C are all open standards. The specs were >> developed and continue to be developed in the open -- and both clients and >> servers (proprietary and open source) are very compliant to them. I'd like >> to propose that our APIs take the same approach. >> >> You are proposing something different than simply implementing HTTP or SMTP. >> What you are proposing that we try to achieve with EC2 what the Wine folks >> want to achieve with the Windows API. It's a different problem. It's a much >> harder problem because it involves reverse engineering and it's prone to >> more risk. >> >> -jOrGe W. >> >> On Jul 8, 2011, at 3:05 PM, Soren Hansen wrote: >> >>> One thing that keeps coming up in this discussion is the issue of >>> "being tied to an API we don't control". >>> >>> People... We're *fantastically* privileged that we get to define an >>> API of our own. Lots and lots and lots of people and projects spend >>> all their time implementing existing (open, but completely static) >>> protocols and specifications. >>> >>> Every HTTP, SMTP, and IMAP server on the planet does it. Every single >>> C compiler on the planet does it. All of these are things that have >>> been defined a long time ago. You can have all the opinions you want >>> about IMAP, but that doesn't mean you can just implement it >>> differently. At least not if you expect people to support your stuff. >>> When there are ambiguities in the spec, sure, you can insist on taking >>> one path even though everyone else has taken a different one, but >>> don't expect the rest of the world to change to accommodate you. If >>> you want to do offer something better by doing something differently, >>> offer it as an alternative that people can switch to once you've won >>> them over. Don't make it a prerequisite. >>> >>> There's a golden rule when implementing things according to an >>> existing specification: Be very conservative in what you deliver, and >>> be very liberal in what you accept. Otherwise, people. will. use. >>> something. else. period. >>> >>> -- >>> 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 >> >> This email may include confidential information. If you received it in >> error, please delete it. >> >> >> _______________________________________________ >> 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
