Open Stack

2011/2/17 Jay Pipes <jaypipes at gmail.com>:
>> One thing we saw in the list and experienced first hand is that your Hudson server uses a pre-configured environment and ours pulls virtual env every time.  We had failures on trunk that yours missed because of new pip pulled versions.
>>
>> A fresh run_tests.sh -f needs to work.  It is the only guaranteed sanity test everybody can replicate.  It might pull upstream bugs, but better to be ahead of that curve than behind.
> Although Soren adequately explained why he thinks that running
> run_tests.sh on Hudson should *not* be against a pip/virtualenv setup,
> I would like to state that I think it would be a good idea to have
> Hudson do *both*.
>
> In other words, for each pre-merge into trunk, Hudson would run two things:
>
> * run_tests.sh -N
> * run_tests.sh -V -f

I understand the motivation, I'm just not sure I want the latter to
actually block a merge. As an example, the recent race condition I
spotted and fixed required a patch to land in eventlet. If the latter
was allowed to block a merge, we'd have to keep a known race condition
in Nova until upstream decides to do a release so that pip could fetch
it. That could take a *long* time. In the mean time, I stuck a fixed
Eventlet package in our PPA (and in Ubuntu Natty proper) so that we
could move on with our lives and get rid of the race condition.
There's simply a flexibility in this approach that I don't see how we
can obtain with the pip approach.

Again, though, I would be *delighted* to have automated testing on a
load of different platforms. I just don't believe they should all be
allowed to block us from moving forward.

-- 
Soren Hansen
Ubuntu Developer    http://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/