Open Stack

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 <eric at 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120423/be3a78a7/attachment.html>