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
* 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.
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
--
Sean Dague
http://dague.net
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
