+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 <[email protected]> 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 : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
