Open Stack

There seemed to be a strong agreement at the summit regarding the need for contracts on those "private" apis. This is because those APIs are no longer really private, they're shared amongst incubated projects.  Furthermore, it seems this may be required to support version heterogeneity during upgrades with versioned RPC calls.

The incubated projects could use REST APIs, but we're talking of introducing artificial scaling and reliability constraints to do that.  It seems far better to me, if we can have contracts on those internal APIs and use them between the incubated projects.  There is a strong enough push to maintain these versions *anyway*.

-- 
Eric Windisch


On Monday, April 23, 2012 at 3:25 PM, Justin Santa Barbara wrote:

> 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 (mailto: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 (mailto: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/6e0a7a34/attachment.html>