Memcache warnings in test run output
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
Francesco Banconi |
Bug Description
As of Fri May 4, we started seeing memcache complaints in the stdout of test runs, like this:
WARNING:
You can see a lot more in this pastebin, from a parallel test run in the data center: http://
Moreover, you can also see these in the non-parallel buildbot output. For instance, search for "WARNING:
In parallel tests, these can completely hose the subunit processing. However, the fix for bug 996729 will hopefully make that problem go away. The bigger problem--the one for this bug, and one not specific to parallel testing--is that the warnings themselves are concerning. It would be nice to know why we are getting these warnings, and either quiet them or do something about them, as appropriate.
According to buildbot, these warnings first started showing up in build https:/
The following are the new checkins for build 2037, according to buildbot. As you can see, the likelihood is that these new warnings are self-inflicted by the squad working on parallel testing. The change to logs is particularly suspicious.
Changed by: Ian Booth <email address hidden>
Changed at: Thu 03 May 2012 23:12:09
Branch: bzr+ssh:
Revision: 15197
Changed files:
lib/lp/
lib/lp/
Comments:
[r=sinzui][no-qa] Moce some storm classes from
lp.bug.
Properties:
Changed by: Benji York <email address hidden>
Changed at: Fri 04 May 2012 00:32:08
Branch: bzr+ssh:
Revision: 15198
Changed files:
lib/lp/
Comments:
[r=jcsackett][bug=992692][no-qa] clear out any existing log handlers
at the start of each test case so tests that add handlers don't
effect those that depend on no handlers being registered.
Properties:
Changed by: Brad Crittenden <email address hidden>
Changed at: Fri 04 May 2012 00:46:08
Branch: bzr+ssh:
Revision: 15199
Changed files:
lib/lp/
lib/lp/
Comments:
[r=gary][bug=987499] Set LaunchBag.developer to False in
lp.testing.
Properties:
Changed by: Gary Poster <email address hidden>
Changed at: Fri 04 May 2012 00:50:09
Branch: bzr+ssh:
Revision: 15200
Changed files:
lib/lp/
Comments:
[r=bac][bug=994158][no-qa] Mark the db as dirty after a cronscript
test so our automatic processes clean the db up for the next test.
I think this bug can be closed when the cause of the warnings is understood and the warnings themselves are no longer emitted (to stdout or, after bug 996729, to stderr when using subunit).
Related branches
- Benji York (community): Approve (code)
-
Diff: 338 lines (+85/-1)11 files modifiedlib/lp/app/browser/tests/test_launchpadroot.py (+10/-0)
lib/lp/blueprints/browser/tests/test_specificationtarget.py (+13/-0)
lib/lp/blueprints/browser/tests/test_views.py (+7/-0)
lib/lp/bugs/browser/tests/test_bugcomment.py (+19/-0)
lib/lp/bugs/tests/test_bugs_webservice.py (+5/-0)
lib/lp/registry/browser/tests/test_distribution.py (+4/-0)
lib/lp/registry/browser/tests/test_distroseries.py (+7/-0)
lib/lp/registry/browser/tests/test_pillar_sharing.py (+4/-0)
lib/lp/registry/browser/tests/test_projectgroup.py (+4/-0)
lib/lp/registry/browser/tests/test_subscription_links.py (+8/-1)
lib/lp/registry/tests/test_distribution.py (+4/-0)
Changed in launchpad: | |
assignee: | nobody → Francesco Banconi (frankban) |
status: | Triaged → In Progress |
Changed in launchpad: | |
status: | Fix Committed → Fix Released |
Comments:
[r=jcsackett][bug=992692][no-qa] clear out any existing log handlers
at the start of each test case so tests that add handlers don't
effect those that depend on no handlers being registered.
That looks like the proximate cause to me; a root:WARNING log will go
to the console in the absence of other handlers.
You might be better off with a FakeLogger or similar fixture to
capture the log messages and attach them to the result (which will
allow developers to see them).
e.g., in setUp: (FakeLogger( ))
self.useFixture
Sadly though, fixtures.FakeLogger doesn't implement the getDetails()
method (it didn't exist IIRC, when FakeLogger was created); that
should be a small patch, which I could either do or review if you
choose to go down that path.
That said, there are three possible reasons for memcache sets to be failing:
- tests run outside the Memcache Layer
- the Memcache Layer config not being honoured properly
- an actual memcache issue.
It seems entirely possible to me that the memcache side of this is
entirely unrelated to parallel testing per se and has been around for
some time.
-Rob