[OpenStack-Infra] [Infra] Meeting Tuesday September 16th at 19:00 UTC
Hi everyone, The OpenStack Infrastructure (Infra) team is hosting our weekly meeting on Tuesday September 16th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone interested in infrastructure and process surrounding automated testing and deployment is encouraged to attend. -- Elizabeth Krumbach Joseph || Lyz || pleia2 http://www.princessleia.com ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
[OpenStack-Infra] Setting the bar higher for stackforge
Howdy, So we're just about to hit the 400th project hosted by the infrastructure team (and there are at least a dozen in review). I think this is great feat although I'm concerned about how our resources are being used. Despite stackforge projects meaning to be self-sufficient they do create extra work for us - at least in terms of reviews (such as adding or tweaking tests). I do think that once they are up and running they are generally low maintenance but they still add overhead in terms of overall complexity and so on. I think it goes without saying that the stackforge programme is an important asset to OpenStack. However, with our current challenges and limitations of the gate and resources I wonder if we should set the bar higher for accepting stackforge projects. I'm not sure how this might look. For example, do we need to closer consider the relevancy of a project; or perhaps if two projects might be able to be joined together. These metrics can be ambiguous and require good insight into the proposed project(s) to tell. Additionally we could require a certain level of maturity in the codebase before accepting a project over to stackforge. However, this would hinder projects being started in the open (which would be a big deal). It might be helpful to look at what we currently have project-wise to determine how tangential or relevant projects are on average. We may also wish to consider ways to mark projects as inactive to begin removing them from our configuration files as a tidy up. Another idea may also be to consider what tests are critical and what could be ran as 3rd party tests for non-incubated projects. Or perhaps working towards testing more tactical[0] on all projects. I'm not actually sure where I sit on this matter myself but I think it's an interesting conversation to flag. Cheers, Josh [0] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041057.html -- Rackspace Australia ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Setting the bar higher for stackforge
On 2014-09-15 23:44:39 +1000 (+1000), Joshua Hesketh wrote: [...] I'm not sure how this might look. For example, do we need to closer consider the relevancy of a project; or perhaps if two projects might be able to be joined together. These metrics can be ambiguous and require good insight into the proposed project(s) to tell. Additionally we could require a certain level of maturity in the codebase before accepting a project over to stackforge. However, this would hinder projects being started in the open (which would be a big deal). I don't see how these distinctions could be anything other than arbitrary, and so whoever ends up tasked with making that judgement will get to endure endless arguments over why some particular project is not a good fit. I don't personally want to be part of that jury--it seems like a lot of effort for little gain. It might be helpful to look at what we currently have project-wise to determine how tangential or relevant projects are on average. We may also wish to consider ways to mark projects as inactive to begin removing them from our configuration files as a tidy up. This also seems like needless makework unless defunct projects are themselves creating a burden or risk. The concerns you raised were primarily over config review activity, I don't think abandoned projects are likely to generate any of that. While I might be tempted by my own personal OCD demons to try and clean up stuff like this, I always remind myself that the effort is unlikely to balance the gains. As for addressing the review burden, I gather an end goal of http://specs.openstack.org/openstack-infra/infra-specs/specs/config-repo-split.html is to be able to broaden the core reviewer team for these and reduce the overall burden on the current infra-core team. Another idea may also be to consider what tests are critical and what could be ran as 3rd party tests for non-incubated projects. Or perhaps working towards testing more tactical[0] on all projects. [...] We already basically draw the line that we don't adjust our general infrastructure provisioning to accommodate unofficial projects (additional node types not used for testing OpenStack itself, additional packages installed by default on workers even though nothing in OpenStack needs them, additional entries into global requirements which are only there to serve StackForge projects, et cetera). If a StackForge project can't use our basic OpenStack test infrastructure to run jobs it needs, then that is an avenue for third-party testing. Some of them already take advantage of that option, so I think this is working as designed? Also, if we analyze the overall test system resource usage, I think we'd find that StackForge project jobs make up a very small percentage of it. They're mostly short-running, the projects tend to have a limited number of jobs (if any) and small or nonexistent integration queues (so the resource impact from their gate resets is nearly nil). I'm not in favor of changing the testing expectations for them unless we have some actual statistics showing that such a change will be worth the time we spend implementing it. -- Jeremy Stanley ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Setting the bar higher for stackforge
From: Jeremy Stanley [fu...@yuggoth.org] Sent: Monday, September 15, 2014 1:06 PM On 2014-09-15 14:36:59 + (+), Sandy Walsh wrote: For our group, the greatest value of StackForge is CLA management. [...] Out of curiosity, why is that a value to your StackForge project(s)? About the only benefit I could see is for projects targeting future inclusion in an official OpenStack Program, so that they don't have to retroactively get the permission of the contributors or their respective employers when that time comes. It's the Corporate CLA that's needed. The companies that want to contribute have already vetted and signed the CCLA. They need protection in case someone contributes something nasty. Accidentally or intentionally. We aren't looking for inclusion in the foreseeable future. Honestly, I was kind of disappointed to lose our github organization and having to mangle our repo names just for organizational purposes. If your end goal is inclusion in OpenStack itself, then that was an inevitable organizational change anyway. OpenStack uses free software to manage its projects, so GitHub is out of the question. Certainly, but code doesn't need to be sanctioned by the foundation to work with OpenStack. Just as logstash, kibana, et al are used currently. If we can make a great widget and our license is suitably permissive, is there a reason we should need inclusion? Would it be possible to just expose/extend/enforce the CLA side of StackForge to repos outside of stackforge git? I fail to see what this would accomplish. The OpenStack Individual Contributor License Agreement only makes sense within the context of actual present/future OpenStack projects (and many of us even question whether it makes sense there). It would let us continue developing our software as we are currently. Business as usual. And it would protect the contributing companies just as the CCLA does today. Getting these companies to vet and sign another CCLA would be very hard to do. And us getting a new CCLA/ICLA in place would be impossible. We are OpenStack users and an OpenStack focused project. We're just trying to do it with minimum bureaucracy. ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Setting the bar higher for stackforge
From: Jeremy Stanley [fu...@yuggoth.org] Sent: Monday, September 15, 2014 2:05 PM On 2014-09-15 16:47:13 + (+), Sandy Walsh wrote: It's the Corporate CLA that's needed. The companies that want to contribute have already vetted and signed the CCLA. They need protection in case someone contributes something nasty. Accidentally or intentionally. [...] Hopefully you understand that Gerrit does not in any way enforce the CCLA for any projects, official or otherwise? Hmm, my understanding was that branches are not accepted without a signed ICLA. Is that not the default case? If we can make a great widget and our license is suitably permissive, is there a reason we should need inclusion? Not at all. It was merely the only reason I could conceive for you wanting to impose the ICLA on your contributors. In fact it sounds like you may have done so due to a misunderstanding? IANAL, so it could very well be. I'll talk with our contributors about that. It would let us continue developing our software as we are currently. Business as usual. And it would protect the contributing companies just as the CCLA does today. Getting these companies to vet and sign another CCLA would be very hard to do. And us getting a new CCLA/ICLA in place would be impossible. I believe this may be a giant error in interpretation of the document, and I strongly encourage you to bring it up on the legal-disc...@lists.openstack.org mailing list since yours may not be the only project making such assumptions. Yep, sounds like further opinion is needed. We are OpenStack users and an OpenStack focused project. We're just trying to do it with minimum bureaucracy. In this case CLA bureaucracy is imposed on official OpenStack projects due to foundation bylaws. There should be no need to inflict this on other projects which are not an official part of OpenStack itself and have no intention of becoming so, and the wording therein may not be providing any protection to unofficial projects and their contributors whatsoever. That's definitely interesting. I'll follow up. I gave [1] a read, which was helpful. But it's not definitive in any way. Jeremy Stanley Thanks for the feedback Jeremy. This could be a great help. [1] https://wiki.openstack.org/wiki/OpenStackAndItsCLA ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Setting the bar higher for stackforge
On 09/15/2014 10:25 AM, Sandy Walsh wrote: From: Jeremy Stanley [fu...@yuggoth.org] Sent: Monday, September 15, 2014 2:05 PM On 2014-09-15 16:47:13 + (+), Sandy Walsh wrote: It's the Corporate CLA that's needed. The companies that want to contribute have already vetted and signed the CCLA. They need protection in case someone contributes something nasty. Accidentally or intentionally. [...] Hopefully you understand that Gerrit does not in any way enforce the CCLA for any projects, official or otherwise? Hmm, my understanding was that branches are not accepted without a signed ICLA. Is that not the default case? It's a per-project config option. If you are a stackforge project, you can chose to not enforce the CLA. However, if you are a stackforge project that has aspirations to becoming an OpenStack project, not having CLA enforcement on while on stackforge could make things sticky for that. If we can make a great widget and our license is suitably permissive, is there a reason we should need inclusion? Not at all. It was merely the only reason I could conceive for you wanting to impose the ICLA on your contributors. In fact it sounds like you may have done so due to a misunderstanding? IANAL, so it could very well be. I'll talk with our contributors about that. It would let us continue developing our software as we are currently. Business as usual. And it would protect the contributing companies just as the CCLA does today. Getting these companies to vet and sign another CCLA would be very hard to do. And us getting a new CCLA/ICLA in place would be impossible. I believe this may be a giant error in interpretation of the document, and I strongly encourage you to bring it up on the legal-disc...@lists.openstack.org mailing list since yours may not be the only project making such assumptions. Yep, sounds like further opinion is needed. We are OpenStack users and an OpenStack focused project. We're just trying to do it with minimum bureaucracy. In this case CLA bureaucracy is imposed on official OpenStack projects due to foundation bylaws. There should be no need to inflict this on other projects which are not an official part of OpenStack itself and have no intention of becoming so, and the wording therein may not be providing any protection to unofficial projects and their contributors whatsoever. That's definitely interesting. I'll follow up. I gave [1] a read, which was helpful. But it's not definitive in any way. Jeremy Stanley Thanks for the feedback Jeremy. This could be a great help. [1] https://wiki.openstack.org/wiki/OpenStackAndItsCLA ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Setting the bar higher for stackforge
On 2014-09-15 17:25:48 + (+), Sandy Walsh wrote: Hmm, my understanding was that branches are not accepted without a signed ICLA. Is that not the default case? [...] Yes, but you specifically mentioned desiring enforcement of the CCLA, not the ICLA. We do have Gerrit configured to require a recorded assent to the OpenStack Project Individual Contributor License Agreement (and by extension an OpenStack Foundation membership under the current implementation) for projects which request such enforcement, but we have no way to enforce an OpenStack Project Corporate Contributor License Agreement from the individual's employer nor an entry for them in Schedule A of that document. Also, if OpenStack itself decides at a future date to drop this enforcement for official projects, the Infrastructure Team will without a doubt cease any and all support for that feature (even for unofficial projects). -- Jeremy Stanley ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
Re: [OpenStack-Infra] Setting the bar higher for stackforge
From: Jeremy Stanley [fu...@yuggoth.org] Sent: Monday, September 15, 2014 2:51 PM On 2014-09-15 17:25:48 + (+), Sandy Walsh wrote: Hmm, my understanding was that branches are not accepted without a signed ICLA. Is that not the default case? [...] Yes, but you specifically mentioned desiring enforcement of the CCLA, not the ICLA. We do have Gerrit configured to require a recorded assent to the OpenStack Project Individual Contributor License Agreement (and by extension an OpenStack Foundation membership under the current implementation) for projects which request such enforcement, but we have no way to enforce an OpenStack Project Corporate Contributor License Agreement from the individual's employer nor an entry for them in Schedule A of that document. Also, if OpenStack itself decides at a future date to drop this enforcement for official projects, the Infrastructure Team will without a doubt cease any and all support for that feature (even for unofficial projects). -- Gotcha ... thanks. I did some more digging. It seems the real issue is pain the github eula causes vs. the pleasure the openstack CLA gives. So, sorry for the red herring. The upshot of the whole thing is other groups may want to bring our project into openstack-proper sooner than later. And, getting visibility of the community in stackalytics would be nice as well. Stackforge, here we come! (thanks again guys) -S ___ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
