[00:04] lifeless: Thoughts on the timeout thing? [00:04] which thing [00:05] See here 50 minutes ago [00:05] uhm, why is the controller destroyed? [00:05] oh, paging it [00:05] in [00:05] .. [00:05] .. [00:05] .. [00:06] Controller destruction and soft request timeouts are both end-request events. [00:06] soft time out is checked at end of request [00:06] it's removed in the endRequest event handler right? [00:06] Yep [00:06] you want the controller info in the oops [00:06] woo components [00:06] so no, thread local values won't help [00:06] you either want the events ordered, or one event [00:07] Ah, so I can't delete a team I own? WTF? [00:07] Well, we don't have the controller info now, and I wanted a quick way out :) [00:07] But OK [00:07] wgrant: poolie put the flag stuff into the oopses for hard oopses [00:09] lifeless, i haven't forgotten the timeline stuff :) [00:09] just so you know [00:09] it's still within shouting distance of the top of stack [00:09] poolie: thanks, I know; it was only last week we chatted [00:11] Maybe I can do the soft timeout in afterCall or so instead. [00:12] Unfortunately I've mostly forgotten how publication works. [00:13] Bah [00:13] GitHub has hung Firefox [00:14] o/ [00:14] clearly you should be using safari [00:21] wallyworld_: Ready to talk? [00:21] wgrant: sure, i'll start mumble === elmo_ is now known as elmo [00:38] In [4]: lp = Launchpad.login_anonymously('fewfw', 'dev', 'devel') [00:38] In [5]: lp.access_policy_services [00:38] Out[5]: [00:38] wallyworld_: ^^ [00:39] * StevenK wonders why deleting a team he owns brings up "There is 1 error" [00:39] wallyworld_: http://pastebin.ubuntu.com/853451/ [01:03] wgrant: i can hear you [01:04] wgrant: i'll restart mumble [01:06] Now, why can't I delete a team I just created? [01:08] delete? Delete? DELETE? [01:09] LPCONFIG=development utilities/create-lp-wadl-and-apidoc.py --force lib/canonical/launchpad/apidoc/ [01:10] lifeless: It says "There is one error" but gives no indication what that is [01:13] StevenK: prod? qastating? dev? [01:16] lifeless: qas [01:16] https://qastaging.launchpad.net/~foobarbazquux [01:16] Ah [01:16] Team deletion won't work [01:16] At all [01:16] Because qastaging's DB is beyond all reasonably definitions of fuckedness. [01:16] Right [01:17] Which means person merge is utterly fucked too [01:17] its being rebuilt as we speak [01:17] StevenK: Deletion is merge. [01:17] wgrant: I'll mark bug 934778 as untestable [01:17] <_mup_> Bug #934778: Typo in informational message after deleting a team

< https://launchpad.net/bugs/934778 > [01:17] At the end of the day, it was a mechnical change anyway [01:18] the robots are revolting ? [01:18] sourcherry is, anyway [01:28] wgrant: Are you done with wallyworld_? [01:29] Not even close :( [01:43] StevenK: We're done now. [01:43] But I'm about to have lunch unless you need something. [01:45] wgrant: Go and have lunch, we can chat about LimitedView after lunch. [01:46] StevenK: Does it provide any immediate benefits? [01:46] Or should we deploy now without it? [01:47] It's not flagged, so if it works as intended it should remove the confusing UI [01:47] Oh, has the template been modified? [01:47] Not as yet [01:47] Then how can it remove the confusing UI? [01:48] Nothing uses LimitedView on Bug, does it? [01:48] I thought the template had been fixed by sinzui [01:48] Didn't you just say the template hadn't been modified? [01:48] How was it tested without an adapter? [01:49] * StevenK was going by what wallyworld_ told him [01:49] hmm? [01:49] yes, the base page template supports rendering entites with limited view [01:50] it won't render the main or side slots for example [01:50] Ah [01:50] just put in a message saying "you cannot see this" [01:50] Not sure it will actually work, though. [01:50] The view init will probably trip over not having View [01:50] Needs testing [01:50] works for teams, and yes, if init touches anything meeding view, you're stuffed [01:51] need to add permission checks if that's the case [01:51] in the init [01:53] wgrant, wallyworld_: http://nowhiring.com.au/424936+job+Prime+Minister+of+Australia+ACT.aspx [01:53] urgh, asp [01:54] i might forward the link to krudd [01:54] Hah [01:54] I hear he has a bunch of free time now. [02:16] wgrant: the top level stuff and navigation rules all work nicely [02:26] wallyworld_: You have a trivial service? [02:37] StevenK: Did you change the traversal check? [02:37] StevenK: I can't traverse to bugs on which I should have LimitedView. [02:38] wgrant: There's a traversal check? :-( [02:40] wgrant: yes, there's a trivial service [02:42] StevenK: That's how it 404s. [02:43] StevenK: You know that this is testable locally, and the view will probably need changes, right? [02:44] wgrant: StevenK: the traversal check has already been changed to only require limitedView IIRC [02:45] The launchpadlib collection check was. I don't know about the bug traversal check. [02:47] i thought it had but could be wrong [02:50] wgrant: So, I think I was led down the garden path a bit by wallyworld_ [02:50] StevenK: it all works fine for teams [02:50] and bugs should be similar [02:50] wgrant: If you point me at the traversal check, I'll look into fixing it [02:50] if it needs fixing [02:51] wallyworld_: wgrant has already stated it does [02:51] do teams use different traversal? [02:51] wgrant: As it is, r14855 is safe to deploy, but it doesn't work. [02:51] the traversal stuff that was changed was in the base publisher [02:51] so it should work for most things, no? [02:52] [13:37] < wgrant> StevenK: I can't traverse to bugs on which I should have LimitedView. [02:52] wallyworld_: Yes, it's separate. [02:52] wallyworld_: ^ [02:52] Only two types of objects have the forbidden-equals-404 check AFAICT [02:52] hopefully only bugs is different then [02:53] # Get out now if the user cannot view the bug. Continuing may [02:53] # reveal information about its context [02:53] if not check_permission('launchpad.View', bug): [02:53] return None [02:53] Ah crap. [02:53] StevenK: You are in for a world of pain. [02:53] StevenK: You need to introduce a new view, basically. [02:53] StevenK: On IBug [02:53] Since IBug doesn't have a +index of its own -- it redirects to the default task. [02:53] Which is private information. [02:54] Perhaps we should introduce a NotSharedWithUserView or something? [02:54] In related news, multitask bugs are hideous. [02:56] Anyway, let's deploy. [02:56] * wgrant deploys. [02:57] wgrant: Including or excluding r14855? [02:57] Including. [02:57] No reason to exclude, really. [02:57] Or a reason to rollback [02:58] Well [02:58] Bug's security declarations are terrible. [02:58] But I don't think it's too holy. [02:59] * StevenK sighs [02:59] Where did my route to the DC go? [03:00] lolxetel [03:01] StevenK: you need to fix Bug's security declarations before you continue. [03:02] We can deploy now, but you must do nothing further on this until you fix them. [03:02] Which you just said were terrible. [03:02] Yes [03:02] They are more terrible than I expected. [03:02] Not fatal, but not good. [03:02] So, my current plan was to look at Curtis' bug and branch so I can unblock him [03:02] But I can't reach the DC [03:03] This is reminding me of when wgrant couldn't. [03:04] qa-meh-itll-do [03:04] qa-wcpgw [03:05] Ah. I think I'm getting TTL expired [03:05] Because L3 are a bunch of idiots [03:08] I think v6 traffic is immune, which is nice [03:09] The DC is also immune to v6, though :( [03:12] Hmmm, the route has changed. I think Exetel may have noticed, since their core is now dropping everything [03:14] 19.|-- 4.69.134.77 88.9% 9 244.9 244.9 244.9 244.9 0.0 [03:14] Muppets. [03:14] 20.|-- 4.69.137.77 88.9% 9 312.1 312.1 312.1 312.1 0.0 [03:14] 21.|-- ??? 100.0 8 0.0 0.0 0.0 0.0 0.0 [03:26] Yay, I can hit the DC again [03:26] Nice how it took Exetel 30 minutes to drop their route to Telstra, since they are the cause. [04:30] What the? [04:30] Look at any bug reported against LP and hover over "Launchpad itself" [04:38] StevenK: Mmm, delicious 2007. [04:42] (2007 + bugs, but still 2007) [04:52] wgrant: So, what needs to happen with the bug security adapters? [04:52] StevenK: They leak tonnes of stuff that needn't be leaked. [04:53] Grab https://bugs.qastaging.launchpad.net/api/devel/bugs/718213/duplicate_of?ws.accept=application/json as anonymous [04:53] <_mup_> Bug #718213: Can't access due to content. < https://launchpad.net/bugs/718213 > [04:53] It's a dupe of bug #1234, which I've made private. [04:53] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts < https://launchpad.net/bugs/1234 > [05:00] Lots of that JSON is redacted [05:01] And lots is not. [05:02] wgrant: What do you want to see disappear? [05:02] Pretty much all of it. [05:02] I don't have access to the bug. [05:02] I don't really need to see much. [05:02] I think the issue is the Indeed. [05:03] Most of them should drop to launchpad.View ? [05:03] Which means anonymous users can't fetch them for public bugs eithwer [05:03] I would suspect so. [05:04] Oh? [05:04] Oh, I'm wrong? [05:04] launchpad.View is held by anonymous users for public bugs. [05:04] I would hope. [05:04] If it's not it's a bug. [05:04] So, id needs to stay, as does private. [05:05] Regrettably. [05:07] [16:06] < Solver> Dodo announced THE INTERNET to Telstra and they accepted it [05:07] Heh [05:07] wgrant: ^ Cause of my DC unreachability [05:08] * StevenK kicks wallyworld_ [05:08] ouch [05:08] That's what you get for importing ILaunchpadCelebrities into bugs.security [05:09] did i do that? [05:09] 14186.3.3 ian.boo | from zope.component import getUtility [05:09] | [05:09] | from lp.app.interfaces.launchpad import ILaunchpadCelebrities [05:10] i should have used personroles [05:10] not sure why i didn't [05:10] moment of madness [05:10] user is already an role [05:11] wallyworld_: I'm putting up a small branch to fix [05:12] ok. i thought by what you were saying you'd do it as a drive by [05:14] No, I don't want to cause other issues in a branch where I'm moving 30 attributes [05:15] StevenK: Be warned, there may be 10 or more tonnes of test fallout. [05:16] wgrant: Yes, which is why I don't want to do any drive-bys [05:16] * wallyworld_ stabs unity/compiz/whatever... restart time :-( [05:19] wallyworld_: https://code.launchpad.net/~stevenk/launchpad/less-celebrites-bug-security/+merge/94313 [05:20] looking [05:21] StevenK: r=me [05:21] thanks for fixing [05:24] Bah [05:24] I wish we were on postgres 9.1 [05:24] Tossing through ec2 just to see if there are any failures [05:46] Bah [05:46] BugHeatUpdater is only 300 times faster. [05:46] Only [05:47] Yes, only. [05:47] Was hoping for more than 1000x. [05:47] Must still be something wrong. [05:47] A penchant for wishful thinking? :-) [05:48] Oh, blah, the bug->task heat mirror trigger. [05:48] Forgot about that. [06:01] wgrant: https://twitter.com/#!/nigelbabu/status/172561507148763136 :D [06:01] I hope I didn't convey that lp is only 300 times faster... [06:01] Heh [06:12] Oh oops. [06:29] Man, "What Could Possibly Go Wrong" should be like the key phrase for LP. [06:41] wgrant: Only 41 failing tests. [07:00] wgrant: Right, http://pastebin.ubuntu.com/853644/ looks pretty good, and has no failing tests. [07:01] Pity default_bugtask, getBugTask and userCanView had to be made public too [07:01] StevenK: default_bugtask does not need to be public. [07:01] The factory goes boom if it is not [07:02] That's not an excuse. [07:02] The factory can log in as an admin or remove the security proxy :) [07:02] userCanView is the excusable. [07:02] s/the // [07:03] Yes. [07:03] getBugTask is not, right? [07:04] Unless you are extremely convincing, it is indeed not excusable. [07:05] I would expect the only public attributes to be id, private, and userCanView [07:05] Possibly not even private :) [07:05] I'm leaving private for the time being [07:05] Yeah [07:05] private isn't leaking [07:06] It's just dirty [07:06] File "/home/steven/launchpad/lp-branches/less-bug-leakage/lib/lp/testing/factory.py", line 1682, in makeBug [07:06] bugtask = bug.default_bugtask [07:06] ForbiddenAttribute: ('default_bugtask', ) [07:07] with admin_logged_in() [07:07] Or rSP [07:07] Probably rSP [07:07] Depending on whether you're returning the task or not. [07:08] No, we're not returning it [07:08] Using it for date_closed and milestone only [07:08] Then you can just unproxy it and nobody will care :) [07:13] This branch is *tiny* [07:13] +7/-9 [07:15] StevenK: and you've got 2 lines for the future :P [07:15] I suspect I have a lot more than that. [07:16] Both wgrant and I tend to remove a lot of code. [08:31] zomg [08:31] BugHeatUpdater caught up [08:32] For the first time in more than a year [08:32] Maybe we will stop having so many oopses now. [08:32] steven@liquified:~/launchpad/lp-branches/less-bug-leakage% subunit-stats < lp.log | grep Failed [08:32] Failed tests: 307 [08:32] Uhoh [08:32] Ah [08:32] Not so bad [08:33] Almost all of them are default_bugtask [08:33] That's why I haven't preemptively euthanised you yet. [08:33] Oh? [08:33] Why would you want to do that? [08:34] Because if they were 307 different failures, you'd want it. [08:34] Haha [08:50] stub: http://people.canonical.com/~wgrant/launchpad/bug-legacy-mirror.sql is my current plan for migration of bugs to the new privacy model. Lets us safely run both schemas in parallel during the migration without worrying about syncing in the app. Rather abhorrent, I know, but it's fast and temporary. [08:51] We have too much data to migrate in a 5 minute window? [08:52] good morning [08:53] stub: Given the interactions with already unperformant bug search, we'd like to be able to revert to the old ways quickly if things don't perform optimally. [08:54] If it is good enough to get past staging, can we tell if any performance issues on production are because of the new schema or because of existing issues? [08:55] Heh, have you tried a bug search on staging? :) [08:56] So we have a new feature we have no way of qaing ? [08:57] Most recent risky performance tweaks have been done by deploying them with feature flags, releasing to launchpad, then beta-testers, then everyone. [08:57] Because staging just isn't good enough. [08:57] I see a fairly complex trigger, so I'm wondering if we can avoid it and the potential for bugs it brings. [08:57] And for stuff like bug search, where there are thousands of different queries... [08:57] Heh, yeah. There is that issue. [08:58] Is the compatibility code more likely to cause troubles than the new work :) [08:58] Will we be hiding use of the new schema behind a feature flag, so most users continue to use the old schema? [08:59] * stub can't even load bugs.staging.launchpad.net... [08:59] stub: Yes, it will all be behind feature flags. [08:59] So we must have the two models running in parallel then. [09:00] Well, we basically have to. Even if we want to just cut over, we'd have to have horrifying views or hybrid appserver code to cope after the change. [09:00] Because we don't have code changes at the same time. [09:00] Populating one schema asynchonously is sucky, so I think we are stuck with a trigger like you have [09:00] I figure doing it this way makes that much easier and safer. [09:00] And lets us back out. [09:00] yup [09:00] The trigger is sucky, yes. === czajkowski changed the topic of #launchpad-dev to: https://launchpad.net/ | Help contact: czajkowski | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad | For packaging help: join #ubuntu-packaging [09:01] gah === czajkowski changed the topic of #launchpad-dev to: [09:02] Much better :) [09:02] stub: The idea is that we get the new schema running in parallel, adjust the bug search code to optionally use it, do lots of performance testing. Based on the results of that, probably implement a flattened bug+bugtask table (which I've already done some testing on, with very promising results). Once we're comfortably on the new schema, dump the old one and make the new one writable and we're in a happy place. [09:03] stub: great start to my day eh === stub changed the topic of #launchpad-dev to: [09:04] wgrant: Yes, this seems the sanest approach. [09:06] stub: Thanks, just wanting to get your veto before I do much more :) [09:06] czajkowski: I have your attempts in scrollback if you don't have the history :) === elmo changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2 [09:07] stub: elmo thanks. [09:08] Aw [09:08] * czajkowski goes and makes another cuppa tea [09:09] wgrant: urgh... using EXECUTE to ensure the query gets planned, rather than using the static plan generated when the procedure was compiled :-( [09:09] stub: I know :( [09:09] I'm not sure what the actual prepared plan is. [09:09] But it takes 20ms rather than 150us [09:10] I just make elmo buy me more hardware. [09:10] :) [09:13] stub: The indices are partial on product IS NOT NULL and distribution IS NOT NULL, so I guess it can't use them unless it knows there aren't any nulls. [09:14] wgrant: Adding redundant 'product is not null' clauses might help there. [09:16] Indeed. [09:16] * wgrant tests. [09:18] Indeed, that works. [09:18] Even a few hundred microseconds faster. [09:19] I guess it will avoid the present prod planning problems, too. === almaisan-away is now known as al-maisan [09:21] Ideally I'd use conditional triggers rather than filtering in plpgsql, but that's not available until 9.0 :( [09:24] Heh, wallyworld_ has landed his two step picker again [09:24] Yep [09:24] Shall we go for two rollbacks? :-) [09:24] i fixed it [09:24] Looked over it this morning, and there're no glaring issues this time. [09:24] s/this time/yet/ ? :-P [09:24] And a global potential XSS fix. [09:24] Can't argue with that :) [09:25] We might even deploy it tomorrow [09:25] wgrant: btw, the launchpadlib api doesn't work with the new services stuff :-( [09:25] wallyworld_: Does so. What doesn't? [09:25] wgrant: lp.load('/services') fails [09:25] There's no reason this shouldn't work, but it might take a bit of poking. [09:25] wallyworld_: What error? [09:26] invalid xml id #service_factory [09:26] because there's no collection exported [09:26] Sinister. [09:26] Do you have a branch? [09:26] Hello [09:26] wgrant: just writing a test or two, give me a few minutes [09:26] wallyworld_: Sure [09:26] mrevell: g'day [09:26] wallyworld_: We should be able to make lp.services.access_policies work as well. [09:27] wgrant: hope so [09:27] mrevell: only a few more days for you to put up with bigjools \o/ [09:29] wallyworld_, We have a band waiting at the air port to see him off. That and big banners with a "Never darken these shores again". [09:29] hah [09:29] mrevell: but now *I* need to deal with him [09:29] no fair [09:40] stub: Want to rebuild bug_fti for hopefully the last time for a while? :) [09:40] stub: The new BugHeatUpdater took 1.5 iterations to do the entire backlog, so that should be it. [09:41] (currently at 67% bloat) [09:46] Hm [09:46] I wonder if I can make update-pkgcache massively faster with SPPH.spn [09:46] That would be nice. [10:06] StevenK: Those 307 errors look pretty easily fixable? [10:10] blink [10:10] There's no SPPH index on (archive, distroseries) :( [10:10] wgrant: I'm not sure, I haven't investigated. I can rSP a lot, but that doesn't fill me with happiness. [10:10] StevenK: In the factory it's fine. [10:10] The factory can commit any evil it wants, as long as the objects it returns are proxied. [10:10] Those 307 are with the factory fixed. [10:10] Ah [10:11] I'll be making the factory commit a loooot of evil in coming months. [10:11] But it should be very fast evil :) [10:15] wgrant: Oh, and that 307 is just -m bugs [10:15] I'm suspecting more fallout [10:19] Should be relatively minor elsewhere. [10:19] I actually expected more. [10:19] Given that you're fixing buggy security declarations from 2005. [10:20] wgrant: wip, https://code.launchpad.net/~wallyworld/launchpad/pillar-access-service-infrastructure/+merge/94338 [10:20] wgrant: i used named utilities to get the services [10:21] so the servicefactory is very simple [10:21] to add a new service, just define it in the zcml [10:21] and that's it [10:21] wallyworld_: Ah [10:21] That's why it won't work in launchpadlib. [10:21] It won't be in the WADL [10:22] You should still be able to say lp.load('/services/accesspolicy'), but not lp.services.accesspolicy [10:22] the servicefactory attribute [10:22] load doesn't work [10:22] lp.load('/services') neither [10:22] Hm [10:22] undefined xml id [10:22] * wgrant tries. [10:22] Did you actually rebuild your WADL? [10:23] yes, several times [10:23] :( [10:23] i may have missed something [10:23] i'm happy how the webservice side of things is working [10:23] It's also possible that launchpadlib is being hilarious with WADL caching. [10:23] maybe [10:23]