openstack team mailing list archive

[Andy Edmonds <andy@xxxxxxxxxx>]

+1 on this. Implementing adapter style code may also introduce additional
state maintenance within the proxy/adapter to the eventual target API and
if not at a minimum more complexity. Also care would be needed to avoid
leaky abstractions [1]. However, I don't necessarily agree that a REST
endpoint (esp. stateless ones like OSAPI) can't be scaled easily.

Justin makes a very interesting point with regard to the non-extensible
nature of the EC2 API (unlike that of OSAPI or OCCI). Perhaps it is an 'API
parity' challenge ( i.e. where API X is functionally equivalent to OSAPI)
and solution (having the ability and maintaining parity) that is key to the
discussion?

.2c

Andy
andy.edmonds.be

[1] http://www.joelonsoftware.com/articles/LeakyAbstractions.html

On Mon, Apr 23, 2012 at 19:01, Eric Windisch <eric@xxxxxxxxxxxxxxxx> wrote:

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