I think the documented 'private' API should be the OpenStack API and should be available to all callers (subject to permissions). I only see downside to having two APIs (public & internal). If a proxy needs additional functionality, odds are it probably belongs in the official OpenStack API because advanced callers (e.g. PlatformLayer) might want the same power.
I think it makes most sense to expose our API via a REST/JSON interface initially (as we do today); if we find performance issues we can expose it via e.g. ZeroMQ/ProtocolBuffers in future. But again, we should do so in a way that benefits advanced callers as well as proxies. Of course, this is heading dangerously towards a purely semantic argument - what _is_ the OpenStack API? :-) On Mon, Apr 23, 2012 at 11:01 AM, Eric Windisch <e...@cloudscaling.com>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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
