yellow team mailing list archive

[Graham Binns <graham@xxxxxxxxxxxxx>]

Okay, so keeping the thread for reference:

Today, it all Just Worked. The 32-core instance yesterday just hung
around and then quit, but m1.small that I accidentally used today
worked fine. Re-running things on a 32-core instance worked fine too.

Except for one small feature: we're still seeing an unknown worker.

For these tests I limited the number of workers to 8 using
--concurrency=8 in master.cfg. There are, however, 9 workers listed -
8 normal and one unknown. The unknown worker log appears to contain
the output from bin/test. Not bin/test --subunit, mind; things like
this:

lp.codehosting.codeimport.tests.test_worker.ForeignBranchPluginLayer:tearDown
lp.codehosting.codeimport.tests.test_worker.TestBzrSvnImport.test_forbidden
lp.codehosting.codeimport.tests.test_worker.TestImportDataStore.test_fetch_with_dest_transport
lp.codehosting.codeimport.tests.test_worker.TestGitImport.test_partial
lp.codehosting.codeimport.tests.test_worker.RedirectTests.test_redirect_to_forbidden_url
lp.codehosting.codeimport.tests.test_worker.ForeignBranchPluginLayer:tearDown
Running in a subprocess.
lp.services.messaging.tests.test_rabbit.TestRabbitUnreliableSession.test_connect_with_incomplete_configuration
lp.services.messaging.tests.test_rabbit.TestRabbitUnreliableSession.test_connect
lp.services.messaging.tests.test_rabbit.TestRabbitUnreliableSession.test_getConsumer
lp.services.messaging.tests.test_rabbit.TestRabbitMessageBase.test_channel_session_closed
lp.services.messaging.tests.test_rabbit.TestRabbitSession.test_disconnect
lp.testing.layers.BaseLayer:tearDown

I've uploaded the entire contents of the lp_devel directory from this
slave, gzipped, to U1 for your joy and edification:
http://ubuntuone.com/4UL3L98uBZCcDHnYqYQy7c. If anyone can shed some
light on what's going on, that'd be a great help to us here. I'm
hoping it's not another "hey, let's muck with stdout" problem...

I'll try again on a --concurrency=20 32-core box tomorrow.