openstack team mailing list archive

[Matt Dietz <matt.dietz@xxxxxxxxxxxxx>]

+1000

I've wanted to see the APIs move to being adapters for the "real" API for some time now. Given the debugging argument alone, I think it's a worthwhile endeavor.

From: Justin Santa Barbara <justin@xxxxxxxxxxxx<mailto:justin@xxxxxxxxxxxx>>
Date: Mon, 23 Apr 2012 08:15:05 -0700
To: Philipp Wollermann <wollermann_philipp@xxxxxxxxxxxxxxxx<mailto:wollermann_philipp@xxxxxxxxxxxxxxxx>>
Cc: openstack <openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>>
Subject: Re: [Openstack] Canonical AWSOME

What's the advantage of replacing the native EC2 compatibility layer with AWSOME from a user / operator point of view?

Although I wasn't able to attend the design summit session, right now we have two "native" APIs, which means we have two paths into the system.  That is poor software engineering, because we must code and debug everything twice.  Some developers will naturally favor one API over the other, and so disparities happen.  Today, both APIs are effectively using an undocumented private API, which is problematic.  We also can't really extend the EC2 API, so it is holding us back as we extend OpenStack's capabilities past those of the legacy clouds.

With one native API, we can focus all our energies on making sure that API works.  Then, knowing that the native API works, we can build other APIs on top through simple translation layers, and they will work also.  Other APIs can be built on top in the same way (e.g. OCCI)

Which is a long way of saying the external approach will result in _all_ APIs (OpenStack, EC2, OCCI etc) becoming more reliable, more secure and just more AWSOME.

Justin

_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp