[occi-wg] Fwd: [Openstack] Third Party APIs

[Alan Sill]

FYI.  Comments (especially on the openstack list) welcome...

Alan

Begin forwarded message:

> From: Vishvananda Ishaya <vishvananda at gmail.com>
> Date: May 17, 2012 1:18:19 PM CDT
> To: "openstack (openstack at lists.launchpad.net)" <openstack at lists.launchpad.net 
> >
> Subject: [Openstack] Third Party APIs
>
> Hello Everyone,
>
> In the ppb meeting last week[1] we discussed third party apis and  
> decided that the policy is not to include them in core.   
> Specifically the motion that passed is:
>
> An OpenStack project will support an official API in it's core  
> implementation (the OpenStack API). other APIs will be implemented  
> external to core. the core project will expose stable, complete,  
> performant interfaces so that 3rd party APIs can be implemented in a  
> complete and performant manner.
>
> So now that we have settled on a long term goal for third party  
> apis, we need to deal with the short term. We do have a stable  
> interface in Nova in the form of the OpenStack API but it remains to  
> be seen whether it is complete and performant enough to allow other  
> apis to be layered on top of it.
>
> Ultimately, I would like to see a stable internal python api that  
> the other apis could speak through (including the OpenStack api  
> layer), but it will probably take a while to get there. In the short  
> term I see three possibilities for third party apis.
>
> 1 Proxy Layer
>
> This is the approach being taken by AWSOME, and it is definitely the  
> easiest to maintain. It has some big advantages, like allowing new  
> apis deployed in a completely decoupled manner. The main potential  
> drawbacks are performance and an incomplete mapping of concepts from  
> one api to another. This will most likely require adding OpenStack  
> api extensions to support some of the extra features in other apis
>
> 2 Separate Project that talks to internal apis
>
> It is possible to write a separate component that imports the  
> compute.api in nova and uses it directly.  This will deal with the  
> performance issues of the above approach, but it runs the risk of  
> being broken if the compute.api changes over the course of the  
> release. The advantage of this approach is it will drive  
> requirements for having a stable/versioned internal api. In this  
> model, automated testing would be necessary to alert any breakages.
>
> 3 Feature Branch in Core
>
> We are doing some work to support Feature and Subsystem branches in  
> our CI system. 3rd party apis could live in a feature branch so that  
> they can be tested using our CI infrastructure. This is very similar  
> to the above solution, and gives us a temporary place to do  
> development until the internal apis are more stable. Changes to  
> internal apis and 3rd party apis could be done concurrently in the  
> branch and tested. Once the branch has stabilized, the updates could  
> be pushed into the internal apis in nova, and the 3rd party api  
> could grow up into its own project like option 2
>
>
> It may be that there are other options that I haven't thought of,  
> but regardless of the approach taken by the various 3rd party apis,  
> I think it is valuable for us all to work together on stabilizing  
> the internal apis.  I'd like the ec2 api to be able to live  
> separately as well.
>
> Vish
>
> [1] http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-05-08-20.00.log.txt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120517/17238da9/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120517/17238da9/attachment.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/occi-wg/attachments/20120517/17238da9/attachment-0001.html>