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?
Cheers, Andy andy.edmonds.be On Thu, May 17, 2012 at 8:18 PM, Vishvananda Ishaya <[email protected]>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 : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
