I'd definitely go for option c here. I'm one of those Core Developers you 
mention that wants less code in the core repos. We also need to make sure the 
right people are maintaining that API code, which aren't necessarily the *-core 
teams.

On May 2, 2012, at 1:02 PM, Vishvananda Ishaya wrote:

> We discussed the policy on third party apis this week at the PPB meeting. We 
> decided to take it to the mailing list for discussion so we can get to some 
> reasonable things to vote on in next weeks meeting.
> 
> tl; dr
> 
> How do third party apis fit in OpenStack?
> 
> Background
> 
> This was inspired by the current proposals for OCCI and CDMI into nova and 
> swift and the upcoming work and proposals for CIMI for nova. The basic 
> question is: does this code belong in the core repositories and if not, where 
> does it go.  I see a number of groups with interest in this. I'm going to 
> outline the major players and give my (biased) opinion on what they want
> 
> a) Core Developers: would prefer to have these apis outside of core. It is 
> already a burden to maintain the existing apis, so separating these into 
> separate projects would be beneficial.
> 
> b) Standards Bodies/Developers: would prefer to have some 
> recognition/discoverability for the new apis, currently the only path forward 
> is to be in core, so they are pushing to be included, but they might be ok 
> with some other type of recognition.
> 
> c) Deployers/Distributors: want an easy way to know that these external 
> plugins work well. This can be accomplished by testing/etc. Probably don't 
> really care too much about the new apis unless they get specific customer 
> requests
> 
> d) Users: some users (scientific community) would love to have access to 
> these other apis.  From a user perspective, the more apis the better, as long 
> as they are stable and all work.
> 
> Current Proposals
> 
> a) ppb doesn't care and the projects decide individually
> 
> b) third party apis are not part of openstack core, and we focus on building 
> a strong ecosystem where these apis could exist as proxies or external 
> plugins. It is up to deployers to decide which ecosystem projects to include 
> in their distributions
> 
> c) just like b, but there is additionally a process by which these third 
> party tools could become 'official' in some sense or be 'recommended' for 
> inclusion by the distros.
> 
> d) third party standards are vetted for inclusion by the ppb and are added to 
> core projects assuming they can pass certain testing requirements
> 
> e) we have our own api, so we shouldn't be encouraging 3rd party apis at all. 
>  Tney are on their own.
> 
> f) ???
> 
> Please discuss,
> Vish
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack-poc
> Post to     : openstack-poc@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack-poc
> More help   : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack-poc
Post to     : openstack-poc@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-poc
More help   : https://help.launchpad.net/ListHelp

Reply via email to