Open Stack

On May 17, 2012, at 11:57 AM, Andy Edmonds wrote:

> Hey Vish,
> In the case of option 2, can such a isolated component remain under the 'nova' module (e.g. the ec2 module under nova/api/) on the nova repository or must it be on a separate repository and yet be, via some means, made easily integrated to the master branch code?

Remaining under the nova module would be option 3 (doing it in a feature branch). Option 2 is putting it in a separate repository.

Vish

> 
> Cheers,
> 
> Andy
> andy.edmonds.be
> 
> 
> On Thu, May 17, 2012 at 8:18 PM, Vishvananda Ishaya <vishvananda at gmail.com> wrote:
> 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
> 
> _______________________________________________
> 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/20120517/8954d2a5/attachment.html>