[00:29] Can anyone disclose acceptably public bits of OOPS-1792H33, pertaining to the current conversation in #launchpad ? [00:40] maxb: what do you need to know? [00:41] maxb: looks like it was having a problem rendering the comments associated with a mp [00:45] jelmer: You say in bug #681974 that you flush, but you need to commit before any other process can see it. [00:45] <_mup_> Bug #681974: build processed with uploadprocessor while it is still set to BUILDING [00:51] wallyworld__: Can you pastebin the traceback, unless you suspect there's private info there? [00:52] lifeless: Ugh, that ec2 run might have hung. [00:52] maxb: i'll have a look [00:52] canonical-config.txt in my local run exploded and hung, and the 600s timeout didn't operate. [00:52] Although it passes fine on its own... sigh. [00:54] maxb: https://pastebin.canonical.com/40201/ === nigelbabu is now known as nigelb [03:47] wgrant: no, it genuinely failed [03:48] lifeless: Huh. Around canonical-config.txt? [03:49] Ah, got it. [03:49] lifeless: It did hang. [03:49] wgrant: ok [03:49] It just also had some proper failures. [03:49] wgrant: I didn't look :) [03:49] wgrant: I meant 'I got mail' [03:49] Thanks. [03:50] I'm rerunning it locally after fixing canonical-config.txt. [03:51] bah, sqlalchemy mappers don't do what I want :( [03:52] These class attributes exist as Python descriptors, and define instrumentation for the mapped class. The functionality of this instrumentation is very rich and includes the ability to track modifications and automatically load new data from the database when needed. [03:58] === Top 10 Time Out Counts by Page ID === [03:58] Hard / Soft Page ID [03:58] 99 / 4871 Archive:+index [03:58] 75 / 256 BugTask:+index [03:58] 13 / 302 Distribution:+bugs [03:58] 10 / 347 Distribution:+bugtarget-portlet-bugfilters-stats [03:58] 8 / 122 ProjectGroupSet:CollectionResource:#project_groups [03:58] 7 / 156 POFile:+translate [03:58] 5 / 96 Question:+index [03:58] 5 / 14 DistroSeriesLanguage:+index [03:58] 5 / 5 ProjectGroup:+milestones [03:58] 5 / 0 DistributionSourcePackage:+filebug-show-similar [04:08] wgrant: tell me when to pull :P [05:01] wgrant: so, how did you go? [05:01] lifeless: Rerunning the test suite, found a couple more failures. [05:01] Still going. [05:02] Just installed a VM in which to run the test suite, so I can develop in parallel. [05:02] Yay for now having lots of RAM.; [05:02] wgrant: and with this, you can run tests in parallel ;) [05:02] how many GB of memory do yiou have? [05:06] lifeless: Well, yes, that's why I'm now so interested in this stuff :P [05:06] 8GiB. [05:06] cool [05:20] lifeless: Quite a few test failures have shown up now that canonical-config.txt is fixed to not obliterate the config. :( [05:21] Most seem to be script-related, though. [05:22] thank you for pulling on tihs [05:25] No more testrunner explosions, so it looks like it was only canonical-config.txt that was being really bad. [05:28] I guess once this is fixed, the librarian stuff should mostly fall into place. [05:28] wgrant: well, I hope so :) [05:28] wgrant: I'm not aware of any actual bugs in the librarian branch [05:28] Well, all the scripts will be using the right config. [07:57] wgrant: any luck? [08:02] lifeless: Been doing other stuff, but looking at various isolation issues now. [08:02] if you want to bounce them around feel free [09:08] Is there a page in launchpad with stats about launchpad? [09:09] like more active projects? [17:35] jml: lp.testing.monkey_patchs looks redundant with testtools patch to me [17:35] jml: does it to you? === Edwin is now known as Guest66935 === _mup__ is now known as _mup_ === nigelb is now known as Guest81825 === elmo_ is now known as elmo === ]reed[ is now known as [reed] [19:39] lifeless_: maybe. will look into it soon. [19:39] * jml gotta run === lifeless_ is now known as lifeless [20:01] wallyworld: http://docs.jboss.org/hibernate/core/3.3/reference/en/html/queryhql.html - you've worked with this in detail, right ? === wgrant_ is now known as wgrant [20:50] * wgrant stabs Windmill. [20:51] good morning to you too [20:51] Morning. [20:51] A few test runs later, I've fixed another couple of issues, seem to be down to fourish real failures. But Windmill hung overnight so I don't know for sure. [20:52] And now the testrunner won't wake up. [20:52] :( [20:53] lifeless: What was your intention with BaseLayer.appserver_config? In some places it's used as a method, in others an attribute. In some it needs to contain a ConfigFixture, in others a CanonicalConfig. [20:54] For now I've moved the fixture to appserver_config_fixture, and things seem to work a bit better. [20:54] mm [20:56] wgrant: its meant ot be a fixture and never a CanonicalConfig [20:56] wgrant: I think you're confused by LayerProcessController [20:56] oh.. I see [20:57] Yes... the method creates a CanonicalConfig. [20:57] And appserver_root_url assumes that it is. [20:57] this is a conflict with devel [20:57] Ahh. [20:57] devel added appserver_config incompatibly. [20:57] I would move the appserver_config method out of the way [20:58] or do config -> config_fixture [20:58] as well as appserver_config -> appserver_config_fixture [20:58] they are paralleled [20:58] Right, I failed to check the origin of the method. Probably should have. [20:58] I've already renamed it to appserver_config_fixture, so I'll do it for config_fixture. [20:58] Thanks. [20:59] note the helper methods that set attributes [21:01] I'm currently setting appserver_config_name whenever the fixture is set. Is that necessary, do you think? [21:03] wgrant: thats what make_config does [21:04] lifeless: It sets the fixture, not the name. [21:04] oh right [21:04] The new method needs the name. [21:04] seems reasonable offhand [21:05] note that the config_name may be set without a config fixture for the persistent test helper case [21:06] Right. [21:06] Apart from occasioanl Windmill hangs, all the layers seem to start now. [21:08] cool [21:08] I'd love to remove the persistent helper case [21:08] but I think things are still a little slow for that [21:34] lifeless: Why'd you remove the DB setup from _runAppServer (r11743)? That causes AppServerLayer to explode when the test before its starting committed, because the DB doesn't exist. [21:34] eg 'bin/test -1cvvvt blacklist_not_public -t TestBugScaling.test_messages_query_counts_constant' [21:35] 'before it' ? [21:35] the commit message makes sense to me [21:35] lifeless: If a test commits, testTearDown drops the DB. [21:35] lifeless: testSetUp will then set it up again. [21:35] yes [21:36] So if the last test in a layer commits, and AppServerLayer is started immediately afterwards, AppServerLayer will start an appserver without a DB. [21:36] what layer are you in [21:36] AppserverLayer.testSetUp should cater for that [21:36] AppServerLayer.setUp starts the appserver.t [21:36] testSetUp hasn't been called at that point. [21:37] so [21:37] to be clear [21:37] a test outside the layer causes the db to go [21:37] but the db layer is still 'live' [21:37] Exactly. [21:37] then the appserver layer is started [21:38] but the invariant of its higher layer being valid is false [21:38] sounds like a bug in the db layer [21:38] / in the layer design [21:38] How can it know that a child is being set up? [21:39] this can break any other layer where the layer setup wants to use the db [21:39] (I've confirmed that calling testSetUp in the children's setUp fixes everything) [21:40] the invariant I'd look for is 'between tests, the db is available, so that child layers can build on it' [21:40] So perhaps testTearDown should recreate it. Hmm. [21:41] Or testSetUp could be called on layer changes. [21:43] so the reason I removed it is it was a layering violation [21:43] Right. [21:45] so [21:46] testSetup is slightly different [21:46] how about this [21:46] http://pastebin.com/z6wZCc9M [21:47] and then [21:47] http://pastebin.com/y1daKate [21:48] thats not quite right [21:50] it will do setUp twice per test which we don't want [21:51] Will it? How's it different from the case where it wasn't dropped in the first place? [21:51] resetting sequences is non-zero time. [21:53] Ah,t rue. [21:54] Pushing this: [21:54] http://pastebin.com/P2i1wbzc [21:54] I've pushed a bit more to mine that you might want to merge. [21:54] I haven't run the db layer tests yet. they may fail. [21:54] k, will try. [21:56] pushed lp:~lifeless/launchpad/databasefixture; whats your branch again ? [21:56] s/lifeless/wgrant/ [21:57] Heh, you committed a syntax errorl [21:57] Missing colon on 697. [21:57] win [21:57] uncommitting ;) [21:57] pull my stuff and I'll get this working and commit. [22:02] pushed [23:18] Windmill tests are sloooooooooow. [23:19] :( [23:19] OTOH I think this run may be clean. [23:19] is that 'page loads are slow' or 'it polls rather than events' or '...' ? [23:19] Both. [23:20] lp.bugs.windmill.tests.test_bug_inline_subscriber.TestInlineSubscribing.test_inline_subscriberNo handlers could be found for logger "lazr.smtptest" [23:20] That can't be right. [23:20] (166.994 s) [23:22] one test ? [23:22] It seems so. [23:22] win [23:23] There's a disturbing number of wats.sleep(5000)s in that test. [23:24] frell [23:29] LOL https://bugs.launchpad.net/launchpad-foundations/+bug/5814/comments/2 [23:29] <_mup_> Bug #5814: want to know breakdown of test run time by area of development [23:29] Ahahaha. [23:30] yes, 9 minute test times being a problem. [23:30] Well, that was only part of the suite. [23:30] no [23:30] it was everything - just not sourcecode/* [23:31] Oh. [23:47] wgrant: still, good news about the branch [23:50] lifeless: 3/4 through the run, four failures which I've fixed. And your fix for the DB thing worked. [23:50] So we may be good. [23:50] wgrant: you're running everything ? [23:51] lifeless: Yes. [23:56] Hrmph. [23:56] test_db_naming_LP_TEST_INSTANCE_set fails. [23:57] bwah