Re: [Openstack-poc] 3rd Party APIs
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. I don't have very strong feelings on that subject. My gut feeling would be to support (c), but I could be convinced by a strong argument why we shouldn't. If that's the decision we end up taking, the PPB discussion quickly shifts to defining the taxonomy of OpenStack projects. On this subject and others that were raised at the Design Summit (like plug-ins), Core/Incubated/Other doesn't really cut it anymore. In particular I'd like to have at least one category for projects that are essential to the OpenStack development community but should not be part of the OpenStack core product (the IaaS stack of projects with a coordinated release every 6 months). Openstack-common, openstack-ci, or things we gate the core product on (devstack, tempest) should never be part of OpenStack Core (or ever be incubated to become core). However they are necessary for us to produce OpenStack core, and require our collective attention and support. So they need to be blessed in some kind of official category meaning they are an central part of OpenStack as a development community. Maybe OpenStack Companion project... Another category could be necessary to describe external projects/plug-ins that are continuously tested with OpenStack Core as part of our integration testing and for which we therefore have a pretty good idea of how well they work with OpenStack. Choosing the right term is a bit more tricky here since most names are a bit overloaded. Maybe OpenStack recommended project/plugin... Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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
Re: [Openstack-poc] 3rd Party APIs
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
Re: [Openstack-poc] 3rd Party APIs
On 05/03/2012 04:08 AM, Thierry Carrez wrote: 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. I don't have very strong feelings on that subject. My gut feeling would be to support (c), but I could be convinced by a strong argument why we shouldn't. I feel the same way. (c) sounds good, but I'm not married to it... If that's the decision we end up taking, the PPB discussion quickly shifts to defining the taxonomy of OpenStack projects. On this subject and others that were raised at the Design Summit (like plug-ins), Core/Incubated/Other doesn't really cut it anymore. In particular I'd like to have at least one category for projects that are essential to the OpenStack development community but should not be part of the OpenStack core product (the IaaS stack of projects with a coordinated release every 6 months). Openstack-common, openstack-ci, or things we gate the core product on (devstack, tempest) should never be part of OpenStack Core (or ever be incubated to become core). However they are necessary for us to produce OpenStack core, and require our collective attention and support. So they need to be blessed in some kind of official category meaning they are an central part of OpenStack as a development community. Maybe OpenStack Companion project... I don't necessarily view openstack-ci and openstack-common in the same vein. I think openstack-common actually should be part of core since it is an important dependency for so many of the core projects (and becoming more so...). Openstack-ci, tempest and devstack are also critical pieces, but they are support projects, not necessarily dependencies. So I would categorize them as OpenStack Supporting Projects or similar. Another category could be necessary to describe external projects/plug-ins that are continuously tested with OpenStack Core as part of our integration testing and for which we therefore have a pretty good idea of how well they work with OpenStack. Choosing the right term is a bit more tricky here since most names are a bit overloaded. Maybe OpenStack recommended project/plugin... The term recommended comes with a lot of baggage :) I don't want plugins to be recommended or suggested -- at least by the community; companies should feel free to recommend or suggest whatever they feel is best for their distro or deployment. I just want a category called OpenStack Extensions (or Plugins, depending on what the semantics-du-jour happen to be. Best, -jay ___ 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
Re: [Openstack-poc] 3rd Party APIs
+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@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 ___ 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
Re: [Openstack-poc] 3rd Party APIs
On May 3, 2012, at 1:16 PM, Jay Pipes wrote: The term recommended comes with a lot of baggage :) I don't want plugins to be recommended or suggested -- at least by the community; companies should feel free to recommend or suggest whatever they feel is best for their distro or deployment. I just want a category called OpenStack Extensions (or Plugins, depending on what the semantics-du-jour happen to be. I agree with this, which is why I support option b --John smime.p7s Description: S/MIME cryptographic signature ___ 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
[Openstack-poc] [Bug 976267] [NEW] auto generate AUTHORS for packaging
You have been subscribed to a public bug: As discussed in bug 920757, the check-ins for all projects are gated using CLA sign. It's not necessary to enforce an entry in AUTHORS file. The file should be auto-generated when we package using python setup.py sdist command. The .mailmap file, if exists, should be honored. This is applicable for all projects, swift, keystone, nova and glance. Once this is resolved, we could remove the test, test_authors.py that check for an entry in AUTHORS file. ** Affects: openstack-common Importance: Undecided Assignee: Bhuvaneswaran A (bhuvan) Status: New -- auto generate AUTHORS for packaging https://bugs.launchpad.net/bugs/976267 You received this bug notification because you are a member of OpenStack Common Drivers, which is the registrant for openstack-common. ___ 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
