openstack-poc team mailing list archive

[Devin Carlen <devin@xxxxxxxxxxxxx>]

+1, primarily by process of elimination.  The other options seem either too permissive or too strict.  I think our job is to provide a way for the ecosystem to develop and give people a place and category for these projects to live, but not to micromanage every piece of the ecosystem.

Devin

On May 2, 2012, at 9:50 PM, Joshua McKenty wrote:

> I'm a fan of c), where the "officialness" is tied to a committed organization or team that is keeping the code up-to-date and tested. I'd also be a fan of making that a per-release designation, with an easy renewal if the commitment is still in place.
> 
> Generally, a smaller core with a "supported" status for satellite projects is my favorite model, for much of OpenStack development.
> 
> --
> Joshua McKenty, CEO
> Piston Cloud Computing, Inc.
> w: (650) 24-CLOUD
> m: (650) 283-6846
> http://www.pistoncloud.com
> 
> "Oh, Westley, we'll never survive!"
> "Nonsense. You're only saying that because no one ever has."
> 
> On Wednesday, May 2, 2012 at 3: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@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack-poc
>> More help : https://help.launchpad.net/ListHelp
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack-poc
> Post to     : openstack-poc@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack-poc
> More help   : https://help.launchpad.net/ListHelp