Make the test suite able to be run in parallel on a single machine

Bug #107371 reported by Jonathan Lange
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
Low
Unassigned

Bug Description

At the moment, you can't run the test suite in the background and continue to work on other branches (in particular, running tests in those other branches). The test suite trashes a single, global database which listens on hard-coded ports, and writes to files in hard-coded absolute paths.

This is a big barrier to running 'make check' on developer workstations.

Changed in launchpad:
importance: Undecided → Wishlist
status: New → Confirmed
Jonathan Lange (jml)
tags: added: build-infrastructure
Revision history for this message
Jonathan Lange (jml) wrote :

Also, being able to run more than one instance of the test suite would allow the test suite to be run more quickly on local machines, since the test suite is known to be CPU-bound.

Revision history for this message
Jonathan Lange (jml) wrote :

Elliot did some work on this.

Also, whoever wants to address these bugs will probably want to file a bunch of related bugs.

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

There are two big areas preventing this:

1) The connection to the database.
2) The use of absolute paths in config values that are contained in-tree, particularly for tests that cross process boundaries.

The former is something of a special case of the latter I guess, but I think it's special enough to deserve its own mention. In particular, fixing this might make it easier for new contributors -- they wouldn't have to mutilate their system postgres databases.

summary: - Make the test suite able to be run in parallel
+ Make the test suite able to be run in parallel on a single machine
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

See https://dev.launchpad.net/FasterTests for some related thoughts.

Revision history for this message
Jonathan Lange (jml) wrote :

I discussed this with Robert Collins. He suggests using chroots to run multiple instances of the test suite on the one machine. This is kind of a cheat, but it's the kind of cheating that I like.

Each chroot can use a different loopback interface, and we can customize the hosts file of the chroot when we create it. We need to be sure that the Launchpad in each chroot is running on a different loopback interface.

<lifeless> jml: chroots
<lifeless> jml: + subunit
<jml> lifeless, chroots don't work around the port problem, I think.
<lifeless> jml: they can have their loopback interace e 127.0.0.2 etc
<lifeless> jml: so with a little alias love, and perhaps the odd patch - yes
<jml> I wonder how much alias love and how odd the patches would need to be.
<lifeless> s/127.0.0.1/localhost/ inside the code base
<lifeless> the alias stuff is triival - ip addr add in a schroot exec script
* lifeless handwaves furiously
<jml> lifeless, the codebase doesn't use 'localhost', it uses things like 'bazaar.launchpad.dev'
<jml> but that's a detail.
<lifeless> those are even easier ;)
<lifeless> thats just hosts in the chroot
<jml> right.
<lifeless> its actually the bind I was talkin about
<lifeless> jml: I don't think it will be complex.

description: updated
Revision history for this message
Robert Collins (lifeless) wrote :

the paralleltest project is implementing this via lxc. \o/

tags: added: parallelteset
Curtis Hovey (sinzui)
tags: added: paralleltest
removed: parallelteset
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.