[00:05] lifeless: So, access policy model. [00:05] StevenK: wallyworld ok, boy is in bed. You guys need anything from me then or are we all set? [00:05] wgrant: shure [00:05] lifeless: The queries end up sufficiently complex that the array indices don't seem to help. [00:06] lifeless: Adding an extra intermediate table to link to multiple policies might perform OK, but it's really hard to say on DF. [00:07] hmm [00:07] I have schemas + populations + queries at http://people.canonical.com/~wgrant/launchpad/access-policies [00:07] how do they perform [00:07] I can't tell. [00:07] DF's performance is too variable. [00:07] would you like me to run some shit somewhere [00:07] rick_h: just waiting for the buildbot upgrade. thanks for asking. next thing is to get the convoy patch done etc but you have that in hand already [00:08] wallyworld: ok cool. [00:08] rick_h: i merged your branch and will land mine as soon as we are ready to go. i'll let you know what transpires today [00:09] wallyworld: ok, sounds like a plan [00:13] lifeless: I'd like if you could experiment a little. There are two there for which performance on qastaging would be interesting. accesspolicy*.sql set up the schema and populate it with real data. The other two are queries for the corresponding schemas. [00:14] are they mutually exclusive ? [00:14] Yes. [00:18] wgrant: your tests are missing analyzes of some temp tables [00:18] and with-arrays has a syntax error [00:19] wgrant: some initial results: http://paste.ubuntu.com/814915/ [00:20] lifeless: The two sets of queries are basically just a dumping ground for things that I tried. [00:20] Unlike the schema bits, they're not meant to be executed in one go verbatim. [00:21] Hah, one of those is for launchpad, the other for ubuntu. [00:24] hmm, I'm surprised at the scope fo rthe CTE working in the second half of the union [00:26] Where? [00:26] A lot of these queries are probably horrible, as I maimed them in horrible ways to try to get different plans. [00:26] OR EXISTS ( WITH teams AS (SELECT team FROM TeamParticipation WHERE person = 21997) [00:26] .. [00:26] UNION [00:26] ... [00:26] teams [00:27] the LP with-arrays example [00:27] Ah, right. [00:27] anyhow, LP is 300ms which is reasonably snappy (for the batch) [00:27] Yeah, that's reasonable for LP. [00:27] Which is the normal case. [00:27] Ubuntu is another story. [00:27] I was able to do any LP thing in 500-700ms on DF. [00:28] its bringing back 5800 bugs [00:28] Hm, I apparently lost the original query at some point. [00:28] so the ubuntu case would be 100 times slower [00:29] That is the one with the current subscription-based queries. [00:29] Right, except it uses a different plan. [00:29] also [00:29] I tihnk the sort is wrong - see the sort bug I filed today [00:30] we do -importance, bugtask.id [00:30] these days, at least for some scopes. [00:30] 5.1 seconds for ubuntu [00:30] -> Nested Loop (cost=0.00..4068090.66 rows=152081 width=69) (actual time=0.206..5084.616 rows=98557 loops=1) [00:33] this [00:33] ORDER BY BugTask.importance DESC, BugTask.id LIMIT 76 [00:33] makes it [00:33] Total runtime: 160.709 ms [00:33] orly [00:34] dunno how well it will scale when you're at offset 5000 (or constraints based that deep in) [00:34] http://paste.ubuntu.com/814929/ [00:35] https://pastebin.canonical.com/58655/ is the current query, for comparison [00:35] so, thats fast because 1/2 the bugs are ubuntu bugs, and the index matches the sort, so it goes 'wha-hay, lets just walk the index' [00:36] Yep [00:36] Like we saw a couple of months abck [00:36] count(*) is Total runtime: 3892.111 ms [00:37] but that is largely separate [00:40] How I envy every other bugtracker :( [00:40] because they don't have to handle our scale? [00:41] Right. [00:41] I guess they also lack bugtasks. === ajmitch__ is now known as ajmitch [00:43] wgrant: I have a possible search schema [00:43] now where did I put it [00:43] That's what I was hoping :) [00:44] http://paste.ubuntu.com/814938/ [02:02] wgrant: does that help ? [02:04] lifeless: Maybe :) [04:58] Hmmmmm. Looks like there is a bug with how nominations check [04:58] * StevenK checks if he can break it, to see if he should notify and redirect [05:04] * StevenK peers at the dev sign-in form. [05:04] Oh yes, wgrant ripped out passwords. [05:05] Yeah [05:05] No passwords for you. [05:08] Hmmmm, if wgrant isn't being evil to DF ... [05:11] I'm not, no. [05:15] wgrant: O hai, Mr OCR -- https://code.launchpad.net/~stevenk/launchpad/notification-already-targetted/+merge/89826 [05:18] StevenK: Shouldn't those permissions work? [05:18] If they're defined at all for those objects, they should surely be transitive. [05:18] wgrant: They don't seem to, and we spent a while hammering out userHas*Privileges() [05:19] So we should use them ... :-) [05:19] Sure, but if there are incorrect launchpad.Driver and launchpad.BugSupervisor for ISourcePackage, we should probably fix that. [05:19] It's fine if they don't exist. [05:19] But not if they exist but are incorrect. [05:20] I think it's being called on a SSP [05:20] Er [05:20] Doesn't only code use SSP? [05:20] s/code/Code/ [05:21] https://bugs.launchpad.net/ubuntu/maverick/+source/libvirt/+bug/632696/+nominate should work for me, I have bug supervisor superpowahs, right? [05:21] <_mup_> Bug #632696: libvirt won't start a VM with serial or console

< https://launchpad.net/bugs/632696 > [05:21] Sure. [05:22] But is that because the permissions are incorrect, or because they don't exist? [05:22] If they don [05:22] don't exist, this fix is correct. [05:22] I'm not sure how to check [05:22] Look for corresponding adapters. [05:23] Or, better still, use bin/harness and try to adapt them :) [05:23] You just lost me [05:23] Check which security adapter happens when you try to adapt ISP to launchpad.Driver or launchpad.BugSupervisor. [05:36] * StevenK drowns in zope calls [05:42] And checkPermission() is utterly incomprehensible. :-( [05:44] IAuthorization(someobj, name='launchpad.Something') [05:45] I was just coming to that conclusion, due to iter_authorization. [05:47] In [5]: IAuthorization(spn, 'launchpad.BugSupervisor') [05:47] Out[5]: 'launchpad.BugSupervisor' [05:48] name= [05:48] The second argh is the default. [05:48] Bah [05:48] -h [05:48] TypeError: 'name' is an invalid keyword argument for this function [05:49] May have to use queryAdapter or getAdapter directly. [05:50] In [16]: auth = queryAdapter(spn, IAuthorization, 'launchpad.BugSupervisor') [05:50] In [17]: print auth [05:50] -------> print(auth) [05:50] None [05:50] spn? [05:51] Bleh [05:51] factory.makeSourcePackage(), and then the above on that results in the same [05:52] That suggests there's no adapter at all. [05:52] So your solution may be correct. [05:52] But check similar for launchpad.Driver [05:52] In [23]: auth = queryAdapter(sp, IAuthorization, 'launchpad.Driver') [05:52] In [24]: print(auth) [05:52] [05:55] wgrant: I had secessfully managed to block lib/lp/security.py from my mind, damn you. [05:56] There are no adapters for ISP at all [06:06] StevenK: Right. [06:06] So your description is incorrect, but your code is right. [06:14] wgrant: "Work around lack of ISP security adapters by using IBugTask.userHas*Privleges()" ? [06:15] StevenK: Something like that. [08:57] good morning === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === matsubara-afk is now known as matsubara [11:10] morning [11:16] ruh roh, did the use-convoy not make it last night? [11:26] rick_h: I don't think buildbot hasn't been upgraded [11:27] Sigh, grammer fail [11:27] heh, ok [11:47] Why is the BranchRevision SQL on the branch page taking 8.8 seconds? :-( [11:47] StevenK: Probably the scanner being a bit greedy with its locks. [11:48] And this is terrible. Thanks the base64 disease in OOPSes, you can't trigger an OOPS on one machine and then eyeball-copy the OOPS to the other. [11:49] It solves more problems than it causes :) [11:59] rick_h: hi, still waiting on the rt to be done before we can land [12:00] wallyworld: ok cool [12:00] i was hoping to be able to tell you it was done [12:00] heh, np [12:00] I need to work off that branch to start work on the other issues so I'm ancy. I'll be patient :) [12:01] i want it done too [12:02] i initially needed to update the rt with the required version info so there was a hold up there, but hopefully there's no more roadblocks === Topic unset by gmb on #launchpad-dev [12:25] Oh, sod it. === gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Firefighting: - | Critical bugtasks: 3*10^2 [12:29] Although, that said... [12:29] * gmb lunches === almaisan-away is now known as al-maisan [13:16] lifeless: you appear not to be subscribed to bug 583426. Are you ok with the dh_python2 namespace approach for lazr? [13:16] <_mup_> Bug #583426: Missing __init__.py < https://launchpad.net/bugs/583426 > === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === matsubara is now known as matsubara-lunch [14:48] abentley, adeuring, rick_h -- hey there, guys. did you guys hold the standup? [14:48] deryck: yes./ [14:49] abentley, adeuring, rick_h -- shall we do it now, or in 10 at the top of the hour? [14:49] deryck: I'm ready now [14:49] either time is fine for me [14:49] yea, fine either way [14:49] ok, let's do it now then. [15:32] bigjools: am I right in thinking that spph.creator wasn't there from the start of copyPackage? i.e. early syncs using that method won't have that set [15:33] Laney: ummmm I can't remember. It's NULL for non-syncs for sure. rvba, can you remember? [15:33] * tumbleweed recalls that being the case [15:34] Laney: bigjools yes, that's true, creator was introduced afterwards. [15:34] hmm OK [15:34] was wondering why we misidentified some early syncs. guess there's no way for us to tell [15:35] Laney: date range... [15:35] tell /who/ synced [15:36] rvba: thanks for the info [15:36] welcome. [15:38] abentley, I'm free now. Sorry it took so long. mumble or g+ hangout? [15:38] deryck: mumble === matsubara-lunch is now known as matsubara [16:15] sinzui: regarding the grackle-lp-views branch. create bug to land, or just land no-qa? [16:15] correct [16:17] jcsackett, I unassigned myself from grackle-client. I need to announce the terminology/use cases decisions from Budapest, and revise interactive mockup to hand off to Huw and Ian [16:18] jcsackett, I will take the card back tomorrow if all goes well [16:18] sinzui: ok. when you say correct, was that to no-qa? could have applied to either clause of my question. :-P [16:19] jcsackett, does it fix a specific bug? [16:19] I think not so no-qa [16:19] sinzui: that's where i was leaning, but i like second opinions. :-P [16:19] is there any auth on the LP oops system? [16:20] i.e. what mechanism do you use to prevent random bozos on the Internet submitting oopses? [16:20] jcsackett, I might be the wrong person to ever ask the question. I QA most of my no-qa bugs because I am paranoid. I would still visit the new view you created and verify the page title and headings [16:21] sinzui: oh yeah, i'm not thinking fire and forget. just whether it's worth filing a filler-bug. [16:21] i think we agree that it's not, but i totally plan on looking at the branch on qastaging. [16:22] jcsackett, I do not think a bug is needed. The view does not provide value to anyone yet [16:24] jcsackett: Are you handling the case where message body is too long? [16:24] jcsackett: I'm a bit obsessed with that right now, because that's the root cause of bug 911090 [16:24] <_mup_> Bug #911090: merge proposal is broken with consistent timeouts < https://launchpad.net/bugs/911090 > [16:25] abentley: our plan is to auto-truncate the body when displaying messages, iirc. [16:25] ...auto-truncate is redundant. [16:25] we'll truncate long messages, and allow another means of seeing the whole thing. [16:25] but we're not a stage where any solution to that is set yet. [16:25] jcsackett: Cool. Yeah, I'm implementing that for comments now. [16:25] abentley: yeah, i can see that being a pain in comments. [16:27] jcsackett: We have three classes of message bodies: Short, long and excessive. [16:28] jcsackett: long and excessive messages get truncated, with a download link. [16:28] jcsackett: long messages also get a "Read more" link that lets you view the message in the Launchpad UI. [16:29] abentley: that sounds like a good solution. i'll ape it so we don't have two means of dealing with the same problem. :-) [16:31] jcsackett: Well, don't go overboard. Since most comments can be adapted to IMessages, maybe we should just move the code to IMessage. [16:31] * jcsackett nods [16:31] abentley: when do you think you're code is likely to start landing? [16:32] jcsackett: this week. Tomorrow if I'm lucky. [16:32] we're doing a lot of incremental landings for grackle integration, and nothing is going to get linked to and really wired in until we can integrate grackle properly, so i can probably move relevant bits into IMessage as i go. [16:32] awesome. i'll take a look as i'm going then and if it works take advantage of that code. [16:33] abentley: moving it into IMessage though may best wait to the day we start moving all of our message stuff into this same archive idea, which i think is longer-range than getting grackle in for mailing lists. [16:34] jcsackett: Part 1 is here, but there's a lot of other stuff: https://code.launchpad.net/~abentley/launchpad/bugcomment-as-icomment/+merge/89497 [16:35] abentley: dig. i think i recall you mentioning some of this at the epic. === al-maisan is now known as almaisan-away [16:44] rockstar: I want to turn ICodeReviewComment.message_body into a method. It used to be one, but you changed it into a property. Can you comment? [16:46] rockstar: (I want to do this because properties are always rendered, and Tarmac is making 16MB message bodies.) [16:46] abentley, *groan* I can't comment. It's been too long. [16:47] rockstar: Okay. [16:47] I think that might have been the result of a code review, actually. [16:48] rockstar: It didn't look like it. I was the reviewer, and I don't remember either. [16:48] Oh, uh, probably ignorance on my part then. [16:50] rockstar: r7719.1.4 if you're curious. [16:51] Oh, it was part of the API! [16:51] leonardr told me to do it that way. [16:51] flacoste: fwiw, the thing I talk about http://code.mumak.net/2012/01/undistract-me.html addresses one of your past concerns about LP's test suite [16:52] jml: i saw! [16:52] rockstar: Doh! [16:53] flacoste: cool :) it's working out really well for me [16:54] abentley, I think there was something about the API decorators that was causing problems. === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno === dpm is now known as dpm-afk [20:01] rick_h: hey [20:01] rick_h: have you looked closely at handlebars? [20:02] jml: our oops system is firewalled off [20:02] jml: we have a plan for a javascript oops system, which will let random bozos submit oopses [20:03] -> automated signal detection will matter, but the fact is random bozos will need access (can't prove a browser was on our website...) [20:05] abentley: perhaps we should reject the 16MB messages (and offer attachments instead) ? [20:08] lifeless: We generally render textual attachments, so I don't think that helps, and I prefer systems that don't have discontinuities. [20:38] abentley: we don't render textual attachments in bugs - at all [20:38] abentley: diffs are a dicontinuity already :) [20:39] lifeless: I'm talking about code review comments. === salgado is now known as salgado-afk [21:45] lifeless: I'm using it for my personal app. I'm liking it so far. [21:46] lifeless: I've not looked at the source much though, so could be evil, but doubt it if YUI is building it into 3.5 [22:04] jcsackett, mumble? [22:34] G'night, all. [22:37] rick_h: use-convoy branch now in ec2 for real :-D [22:37] It was for real last time, too. Now it will land if the tests passs. [22:38] s/\(ss\)s/\1/ [22:38] StevenK: that's what i meant by "for real" [22:39] Hah, another vuln in wordpress <= 3.3.1 [22:43] awesome [22:43] stevek I might need a hm. f [22:43] bah [22:44] a hand with some make/buildout magic to help tests setup [22:44] I think we're still going to want a copy of yui and such in build/js [22:53] rick_h: so, you have the convoy patch sorted, and are now looking at the tests? the first thing i'd do is change the yui seed script location in all the html files so that it doesn't use the symlink in icing [23:13] wallyword yea, I had a discussion with deryck on it today. I think the key will be pointing all seed files at the build js directory and create a symlink there to change yui versions as required [23:17] rick_h: hey hey [23:17] howdy [23:18] rick_h: so yeah, I've been looking at it to asses a pybars port [23:18] lifeless: ah, nice [23:30] rick_h: what you say above about yui tests matches how i envisaged it would work also [23:31] wallyworld: yea, so I'm working on my make/buildbot skills because right now things are built straight into the convoy directory [23:31] and we'll need a new command to move the symlink in the build/js directory from one version of YUI to another and such [23:31] I did it with a bunch of magic JS code today and deryck suggested I might have overcomplicated the issue a little bit :) [23:33] yeah, kiss is good [23:34] it's ok, I got the oreilly gnu make book and I'm starting to try to make it less scary for me [23:34] a goal here for me at least is to totally remove the yui symlink and anu other build cruft from the icing dir [23:35] right, I'm making sure nothing but the link to combo.css comes from icing any more [23:35] sounds good [23:35] anyway, work for tomorrow. Good luck with the landing [23:35] time to work on getting the boy to bed [23:35] thanks :-) will let you know [23:43] rick_h: blah, elocal [23:44] rick_h: so, it seems to me that handlebars has kindof missed the 'separation of code and presentation' angle of moustache [23:44] rick_h: I was wondering if you had any insight into that [23:46] wgrant: QA for r14717 [23:48] lifeless: I find it provides a decent middle ground. You can define new blocks and helpers [23:48] but it's still fairly limiting as a template language goes [23:49] I mean, I know there's a very anti-code in the templates kind of thing, but I also feel that view belongs in the view (template) and things like concat'ing, prettying dates, etc aren't model duties [23:50] lifeless: which part do you find crosses the border? [23:53] wallyworld: Can you look at kanban and see if any cards can move? I know the convoy one can't yet, but some others may be able to [23:53] ok [23:54] StevenK: the two cards in landing are part of the use-convoy branch, so there's nothing obvious to move [23:55] wallyworld: Right [23:56] rick_h: e.g. on here http://handlebarsjs.com/ - the 'list' helper. [23:56] rick_h: seems like a terrible reason to have that facility. [23:57] wgrant: I have a deployment request prepared for when we're good.