Re: [openstack-dev] [all] setting the clock to remove pypy testing
Excerpts from Sean Dague's message of 2015-05-14 08:53:31 -0400: We've disabled all the pypy tests across OpenStack because it was failing, and after 48hrs no one was actually working on any fixes. It's thus effectively just burning nodes for no value. The original thread, for reference: http://lists.openstack.org/pipermail/openstack-dev/2015-May/063720.html It's not clear that there are any active contributors to OpenStack that find the pypy use case interesting enough to stay on top of it. A failure in this non main path blocks a ton of projects from landing any code. I would recommend we set the following remove criteria for June 1st - 2 weeks out. +1 * the pypy jobs all need to be passing again * there are 2 champions that have come forward that will be active in #openstack-dev, #openstack-infra, and #openstack-qa that will commit to actively keeping an eye on such things. I wonder if we have a place yet where we are documenting champions like this? They aren't quite liaisons so I'm not sure the CrossProjectLiaisons page in the wiki makes sense. We could list these on the QA page somewhere, but there are probably other themes for which we need champions, though, so maybe we should make a new Champions page and start making lists so it's easier to find someone to help with non-mainstream issues like this. I feel like we need 2 champions because we need a hot spare (people go on vacation, have other distractions, having only 1 person able to do a thing means the responsibility is really thrust back onto -infra and -qa folks). I'd expect these champions to be the ones that fix the current pypy issues. +1 to having 1 champion for anything like this I think the original theory of pypy is that we would rub cheetah blood on OpenStack and make it magically faster. But, as has been discussed in other threads: control plane services aren't being slowed down by python, they are being slowed down by other solvable architecture changes. data plane services (like swift) aren't helped enough by pypy for performance critical paths, and are thus looking into alternative languages for those parts. -Sean __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] setting the clock to remove pypy testing
On 15 May 2015 at 00:53, Sean Dague s...@dague.net wrote: We've disabled all the pypy tests across OpenStack because it was failing, and after 48hrs no one was actually working on any fixes. It's thus effectively just burning nodes for no value. It's not clear that there are any active contributors to OpenStack that find the pypy use case interesting enough to stay on top of it. A failure in this non main path blocks a ton of projects from landing any code. I would recommend we set the following remove criteria for June 1st - 2 weeks out. * the pypy jobs all need to be passing again What about just the end user ones. heatclient etc; no servers? [see below] * there are 2 champions that have come forward that will be active in #openstack-dev, #openstack-infra, and #openstack-qa that will commit to actively keeping an eye on such things. I feel like we need 2 champions because we need a hot spare (people go on vacation, have other distractions, having only 1 person able to do a thing means the responsibility is really thrust back onto -infra and -qa folks). I'd expect these champions to be the ones that fix the current pypy issues. Agreed. I think the original theory of pypy is that we would rub cheetah blood on OpenStack and make it magically faster. But, as has been discussed in other threads: Yeah, thats not a reason for pypy (today). Though - pypy is faster than go head-to-head in my previous benchmarking work, so I'd be interested in the details of the swift go comparison methodology, if performance is the key thing being looked for. CSP as a way of writing concurrent programs seems like a stronger argument to me... Anyhow, I hope we do find two champions for the client libraries, because I believe in enabling as many people as possible to use our clouds; and just like we have php sdk, it would be great to know that our python sdk's work on pypy too. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] setting the clock to remove pypy testing
On Thu, May 14, 2015, at 05:53 AM, Sean Dague wrote: We've disabled all the pypy tests across OpenStack because it was failing, and after 48hrs no one was actually working on any fixes. It's thus effectively just burning nodes for no value. I think my change to upgrade virtualenv on our test nodes should've fixed the PyPy jobs. Some spot checks earlier in the weeks seemed to confirm that it had done so. (It is possible we have a stray old image in a particular provider that needs updating though). It's not clear that there are any active contributors to OpenStack that find the pypy use case interesting enough to stay on top of it. A failure in this non main path blocks a ton of projects from landing any code. I would recommend we set the following remove criteria for June 1st - 2 weeks out. * the pypy jobs all need to be passing again * there are 2 champions that have come forward that will be active in #openstack-dev, #openstack-infra, and #openstack-qa that will commit to actively keeping an eye on such things. While I think I fixed it this time, I did so more because we needed newer pip for other reasons and getting that required upgrading virtualenv. I did not do it because I have a specific interest in PyPy. I would likely be a bad champion for this cause so am definitely not volunteering here :) Clark __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
