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 <[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
