openstack team mailing list archive

[Eric Windisch <eric@xxxxxxxxxxxxxxxx>]

Creating a contract on the private API will allow the external APIs to be created and tested without needing a translation layer, even if contributory APIs were developed outside of the project (such as in AWSOME).

It is clearly better, architecturally, if the EC2/OCCI apis can access the internal apis directly. The RPC and database can be made to scale in Nova, but a REST endpoint won't be as reliable or scale as well. 

-- 
Eric Windisch


On Monday, April 23, 2012 at 11:15 AM, Justin Santa Barbara wrote:

> > 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
> 
>