[03:27] <wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/dkimpy/+merge/197637
[03:34] <StevenK> wgrant: I'm off today
[03:34] <wgrant> StevenK: Ah, I see.
[06:16] <stub> That was smart. I'd managed to disable nearly all of test_gc with an incorrect inheritance order :-/
[06:18] <stub> No, that should be correct. wtf are my tests not being discovered?
[06:22] <wgrant> stub: How're you running them?
[06:22] <wgrant> stub: The test failures showed up with -t lp.services.librarianserver here
[06:22] <stub> bin/test -vv test_gc
[06:23] <stub> Yes, found and fixed them. But also noticed I'm only running 6 tests from librarian_gc
[06:25] <wgrant> stub: Hm, that finds them all on 2.6 here
[06:42] <stub> wgrant: Do the rest pass btw?
[06:43] <stub> oh, of course they don't
[06:43] <wgrant> stub: Everything in lp.services.librarianserver passes, apart from the GC MD5 issues, and the 2.7ism, IIRC
[07:06] <stub> Seems to be removing duplicate tests, and deciding that because the tests are defined on the Base they shouldn't be run on the subclass (despite the Base not mixing in TestCase)
[07:08] <wgrant> Hm, that's weird.
[07:16] <stub> I've used the same pattern in the past, so we should confirm the test count from the precise buildbot.
[07:17] <wgrant> I checked before, it's only about 50 below the devel one, but that includes layer setup/teardown so it would need manual diffing
[07:22] <lifeless> are you inheriting the base you think you are?
[07:28] <stub> Yeah, I'm got print statements in the setUps at the moment
[07:28] <stub> LibrarianSwiftGarbageCollectionTests inherits (LibrarianGarbageCollectionTestsBase, lp.TestCase)
[07:29] <stub> LibrarianGarbageCollectionTestsBase has no base classes (apart from object)
[07:29] <stub> lp.TestCase inherits (testTools.TestCase, fixtures.TestCaseWithFixtures)
[07:32] <stub> Cute: http://paste.ubuntu.com/6518444/
[07:34] <stub> test.py test_gc trims some tests, test.py --test=Swift can find them though. Neither get tests defined in the base class
[07:36] <wgrant> It's probably to do with 2.7's discover support
[07:36] <wgrant> In which case it won't affect full test runs
[07:37] <stub> http://bazaar.launchpad.net/~stub/launchpad/swift-librarian/view/head:/lib/lp/services/librarianserver/tests/test_gc.py for anyone playing along at home
[07:37] <stub> wgrant: I can land it and see what happens... just need to revert if the tests don't get run
[07:38] <wgrant> Yeah, easy to check from the subunit :)
[07:38] <wgrant> But I think it should be fine.
[10:38] <wgrant_> stub: Are you looking at the GC test failures?
[11:35] <stub> wgrant: Back from blinner, I'll look now
[11:38] <wgrant> stub: Thanks.
[11:39] <stub> One failed test, run twice. Maybe a trivial fix.
[11:55] <stub> wgrant: Can I land http://paste.ubuntu.com/6519343/  with it?
[11:56] <stub> That is how I can get the tests running locally. Certainly something crappy in test discovery in py2.7 or some test helper I have.
[11:57] <wgrant> stub: I'd prefer not to have a workaround in that one file...
[11:57] <wgrant> (to run them locally I just use '-t test_gc' to do pattern matching on the whole test name)
[11:57] <wgrant> Rather than specifying a module, which will invoke 2.7's new discover logic.
[11:58] <stub> Ok.
[11:59] <stub> wgrant: testfix? http://paste.ubuntu.com/6519365/
[12:00] <stub> oh, two redundant lines
[12:00] <wgrant> stub: Are content_* used anywhere?
[12:00] <stub> nuking
[12:00] <wgrant> Yeah, that
[12:00] <wgrant> Otherwise it looks fine :)
[12:01] <stub> http://paste.ubuntu.com/6519371/
[12:01] <stub> k
[12:03] <stub> wgrant: Apart from large files and pulling the Swift creds from a config file rather than the environment, can you think of other stuff we need?
[12:03] <wgrant> I don't think so.
[12:03] <wgrant> Maybe?
[12:05] <stub> I'll do the config file branch, then we can see what we trip over on staging I guess.
[12:05] <wgrant> Yeah
[12:06] <wgrant> Not quite sure how to fully test it there. Might want to inject a lot of files into the staging librarian, I suppose?
[12:28] <stub> wgrant: Last time I checked I had about 250GB I could play with
[12:30] <stub> wgrant: We need to confirm it serves files reliably (small and large), and that the disk-> swift tool works reliably in non-destructive mode.
[12:31] <stub> So I guess rsync over a subtree, push it in, suck it back out from the Librarian.
[12:32] <stub> Or just generate and upload some random content
[12:35] <stub> But the first real test is that nothing acts any differently, since we haven't turned on the FF.
[12:35] <wgrant> stub: Did you forget to land that with [testfix]?
[12:35] <wgrant> It doesnt' seem to have made it in
[12:36] <wgrant> stub: Yeah, that QA plan sounds relatively sane
[12:36] <stub> Proposed commit message:
[12:36] <stub> [testfix][r=stub][bug=1257636] Fix broken test_gc.py
[12:36] <stub> Edit before sending? ([y]es, [n]o): Connection Timeout: disconnecting client after 300.0 seconds
[12:36] <wgrant> Heh
[12:36] <stub> attention fail ;)
[12:38] <stub> The new house I'm moving too should have 1Mb/s uplink on Friday. Been stuck on 4Mb/512kb for too long.
[12:44] <wgrant> stub: 20M/512K here :/
[12:44] <wgrant> Australian HFC providers have a thing for 40:1...