Open Stack

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
>