[02:00] <LPCIBot> Project db-devel build #691: FAILURE in 5 hr 43 min: https://lpci.wedontsleep.org/job/db-devel/691/
[07:40] <LPCIBot> Yippie, build fixed!
[07:40] <LPCIBot> Project db-devel build #692: FIXED in 5 hr 40 min: https://lpci.wedontsleep.org/job/db-devel/692/
[23:08] <wgrant> Morning.
[23:12] <lifeless> wgrant: olá
[23:14] <wgrant> Barely.
[23:15] <lifeless> we have a 150cm climbing tree for the cats
[23:15] <lifeless> they are both wrestling at the top of it right now
[23:18] <wgrant> :(
[23:19] <lifeless> and now are sleep on each other
[23:22] <lifeless> wgrant: are you planning on working today or just going 'blargh'
[23:22] <wgrant> lifeless: Going to try to get us deployable, then blargh.
[23:22] <lifeless> wgrant: if the former, I heard a rumour you'd made progress on rabbit
[23:22] <wgrant> And maybe try to get rabbit sorted out.
[23:22] <wgrant> Since that is mostly poking spm and considering packaging rabbitmq-management.
[23:23] <lifeless> rabbitmq-management ?
[23:23] <wgrant> A plugin which provides an HTTP API which will allow us to reset the fixture in a couple of ms.
[23:23] <lifeless> cool
[23:23] <wgrant> Natty has a plugin or two packaged, so it should be easy enough.
[23:23] <lifeless> did I tell you that db resets are 0.2s
[23:24] <wgrant> gary says they were taking 4s for him (when using the JS factory/teardown bindings written last week).
[23:24] <wgrant> I need to investigate that this week.
[23:24] <wgrant> Since it sounds implausible.
[23:24] <wgrant> By a factor of 10 or so.
[23:25] <wgrant> lifeless: Did you see the stub/bigjools Messaging API v3 land?
[23:27] <lifeless> kindof
[23:33] <lifeless> wgrant: what was taking 4s?
[23:36] <wgrant> lifeless: I'm not entirely clear on that. But it was one of the normal layer teardowns, AIUI.
[23:36] <wgrant> It only came up during the wrap-up.
[23:36] <lifeless> so
[23:36] <lifeless> if there is any contention on the template db
[23:36] <lifeless> both copies will fail
[23:36] <wgrant> I suspect there was an appserver still running or something.
[23:36] <lifeless> and they take their own time about it
[23:36] <wgrant> Since it's in the YUITestLayer-with-appserver monstrosity.
[23:37] <lifeless> can I get a review of https://code.launchpad.net/~lifeless/launchpad/paralleltests/+merge/66554 ?
[23:38] <StevenK> No, since the diff hasn't generated yet. :-P
[23:38] <lifeless> it won't
[23:38] <lifeless> the scanner blew up
[23:39] <lifeless> bzr diff -rr ancestor:lp:launchpad https://code.launchpad.net/~lifeless/launchpad/paralleltests
[23:39] <lifeless> should get you a diff
[23:39] <StevenK> Then pastebin it? :-)
[23:40] <lifeless> sure
[23:42] <lifeless> I've linked a pastebin into it
[23:42] <StevenK> I reserve the right to sob and cry and state it's too hard to review while jetlagged.
[23:42] <lifeless> of course
[23:42] <lifeless> this is just test plumbing
[23:43] <lifeless> it should fix the parallel test job hanging
[23:44] <StevenK> To my jetlagged adled brain, it looks fine.
[23:44] <StevenK> I approve of more logging.
[23:45] <lifeless> the logging is crude, but it helped me a lot when fiddling with it, and I expect others will need said fiddling themselves
[23:45] <lifeless> e.g. future me
[23:46] <StevenK> lifeless: As an aside, I'm curious how the scanner blew up on the branch?
[23:47] <lifeless> StevenK: bug 612171
[23:47] <_mup_> Bug #612171: Error generating merge proposal diff when "source branch has pending writes" <code-review> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/612171 >
[23:47] <StevenK> lifeless: I've approved the branch, land it, ping me when it has and I'll re-enable the Jenkins job.
[23:47] <lifeless> I hit that
[23:47] <lifeless> (I'm using the term scanner loosely)
[23:48] <StevenK> I wonder if we could fix that using Julian's work to suspend the job
[23:49] <lifeless> you could
[23:49] <StevenK> If .checkReady() returns False, suspend the job for one run and unsuspend it on the next run.
[23:49] <lifeless> I think its simpler to just cancel the job cleanly
[23:49] <lifeless> and when scanning a branch, we should be updating the merge proposal(s) for it anyway
[23:49] <StevenK> It will or will not get scanned again by itself?
[23:50] <lifeless> right
[23:50] <StevenK> That was a question, not a statement. :-P
[23:50] <lifeless> 'write pending' is a state that will either rectify itself (and thus the rectification can create new merge proposal jobs), or it won't (and thus a suspended job would never succeed)
[23:51] <StevenK> Right. Then I agree with you.
[23:51] <lifeless> polling every run is inefficient and can fail horribly (when the things being polled but not active grows large)
[23:51] <StevenK> We should kill the job
[23:52] <lifeless> I suspect we have a hole in our 'create a new mp job' logic at the moment, the flip side of this error
[23:52] <lifeless> another option would be to ignore the pending write, and read the *old* tip
[23:52] <lifeless> anyhoo