openstack team mailing list archive

[Lorin Hochstein <lorin@xxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp