[TIP] Nosejobs!

Jesse Noller jnoller at gmail.com
Fri Apr 10 11:25:23 PDT 2009

On Fri, Apr 10, 2009 at 2:21 PM, Michael Foord
<fuzzyman at voidspace.org.uk> wrote:
> Jesse Noller wrote:
>> On Fri, Apr 10, 2009 at 1:41 PM, Doug Philips <dgou at mac.com> wrote:
>>> On or about Thursday, April 09, 2009, at 03:01PM, Jesse Noller indited:
>>>> Let me also point out that I want something to start running tests
>>>> which could run for a week+ - I have internal tests which could take
>>>> 14 days to run. I don't feel like maintaining a client/server
>>>> connection for that long.
>>> If the test dies after 30 minutes and you don't find out about it for 13+
>>> more days?
>>> There has to be a middle ground between a constant connection and a moon
>>> shot. Even moon
>>> shots steer along the way. :)
>> Simple, solved problem. The master(s) track outstanding jobs and check
>> on a customizable interval, if the slave fails to report: It's dead,
>> if the test-runner fails to report to the client-server after the
>> client-server gets a poll from the slave; it's either busy, or dead.
> Advantage of controlling the tests on the slaves with a master process (but
> we're into implementation details here) is that it is easy for it to
> continue its scheduled tests after a wedge. We also use this so that
> individual test processes can be restarted after their memory use gets too
> high.
> Michael

Yup, you don't get that luxury running it in SSH, unless you
SSH->Master Process->testrunner->test. And given SSH is a crappy
management interface for things like this (don't get me started) I
would much rather build a lightweight "master process" daemon.


More information about the testing-in-python mailing list