## Template for LP Production Meeting logs. Just paste xchat log below and the format IRC line will take care of formatting correctly #format IRC #startmeeting Meeting started at 10:00. The chair is matsubara. Commands Available: [TOPIC], [IDEA], [ACTION], [AGREED], [LINK], [VOTE] * flacoste (n=francis@canonical/launchpad/flacoste) has joined #launchpad-meeting Welcome to this week's Launchpad Production Meeting. For the next 45 minutes or so, we'll be coordinating the resolution of specific Launchpad bugs and issues. [TOPIC] Roll Call New Topic: Roll Call me me me/2 me * intellectronica (n=tom@intellectronica.net) has joined #launchpad-meeting only half of you henninge ? :-) stub, hi rockstar, hi me bigjools, hello ni! me matsubara: yes, sorry, concurrent meeting in #ubuntu-meeting ok, everyone is here Ursinha sends apologies as she's still ill [TOPIC] Agenda New Topic: Agenda * Actions from last meeting * Oops report & Critical Bugs * Operations report (mthaddon/herb/spm) * DBA report (stub) [TOPIC] * Actions from last meeting New Topic: * Actions from last meeting * Ursinha to talk to flacoste about buildbot and storm updating for testing when he's available today I've asked Ursinha and she did that so, moving on [TOPIC] * Oops report & Critical Bugs New Topic: * Oops report & Critical Bugs I have 1 bug and 2 oopses for today. bug 394560 for malone, OOPS-1274A1231 for translations and OOPS-1274ED146 for registry Launchpad bug 394560 in launchpad "LookupError: unknown encoding: processing email" [Undecided,New] https://launchpad.net/bugs/394560 https://devpad.canonical.com/~jamesh/oops.cgi/1274A1231 https://devpad.canonical.com/~jamesh/oops.cgi/1274ED146 who should I talk to to update ubottu oops urls? [action] matsubara to chase owner of ubottu to update the oops url ACTION received: matsubara to chase owner of ubottu to update the oops url intellectronica, I need to try to reproduce bug 394560 and add more info Launchpad bug 394560 in launchpad "LookupError: unknown encoding: processing email" [Undecided,New] https://launchpad.net/bugs/394560 intellectronica, once I do that, do you think you can assign someone for a fix? matsubara, you should chase the owner with a bit of wood. * intellectronica looking rockstar, you mean like a club? i hate to say this, but this looks like a Foundations issue :-( hehe * salgado has quit (Read error: 60 (Operation timed out)) matsubara: sure, i'll assign to myself and investigate. i have no idea, off the top of my head, what the problem is flacoste, intellectronica: ok, I'll try to reproduce the issue today and let you know. I'll move the bug to the right project accordingly matsubara, :) intellectronica: well, it seems that we are trying to decode the string based on the encoding specified in the email and that encoding is x-unknown which of course doesn't exist [action] matsubara to reproduce bug 394560, add more info and work with team responsible to have it prioritized so i'd say from the face of it it's a client-side problem ACTION received: matsubara to reproduce bug 394560, add more info and work with team responsible to have it prioritized Launchpad bug 394560 in launchpad "LookupError: unknown encoding: processing email" [Undecided,New] https://launchpad.net/bugs/394560 matsubara: that oops is covered by bug 394224 Launchpad bug 394224 in rosetta "More unique constraints in updateTranslation" [High,Triaged] https://launchpad.net/bugs/394224 henninge, I see it's already triaged and prioritized, so thanks! * salgado (n=salgado@canonical/launchpad/salgado) has joined #launchpad-meeting flacoste: yeah, if that's the case then it's not a bug sinzui, the other one is a OOPS-1274ED146 a timeout on team membership view https://devpad.canonical.com/~jamesh/oops.cgi/1274ED146 sinzui, it's issuing > 3000 queries so it probably can be optimized further [action] matsubara to file a bug for OOPS-1274ED146 https://devpad.canonical.com/~jamesh/oops.cgi/1274ED146 ACTION received: matsubara to file a bug for OOPS-1274ED146 https://devpad.canonical.com/~jamesh/oops.cgi/1274ED146 flacoste: or maybe it's worth coercing x-unknown to None, if that's a common behaviour for mailers This looks just like the timout for merging teams matsubara: I will ask Edwin to look into this since the problem look identical sinzui, thanks. once I have a bug for it I'll assign to him sinzui, looking at the page where the oops happened, doesn't seem related to team merge The two repeat queries are the same that I looked at two hours I see. I'll file a bug anyway and can dupe later on to the team merge bug if that's the case sinzui, thanks matsubara: We have a systemic problem in that we do not have a standard method to get a lot of IPerson sinzui, so the fix for the team merge one will include such a method? No not at all, We need a big spec to fix a systemic problem * sinzui created a spec yesterday to end the nightmare of deactivated account being members or owners of other Launchpad objects sinzui, by spec you mean a blueprint or a new story or something else? I mean both. It is a project that requires lots of planning and breakdown into work for the critical bugs: we have two, one in progress which the fix is ready (according to the bug report) and another one in Triaged state bug 391903 and bug 390563 Launchpad bug 391903 in launchpad-code "Scanner user needs more database permissions" [Critical,In progress] https://launchpad.net/bugs/391903 Launchpad bug 390563 in bzr "absent factory exception from smart server when streaming 2a stacked branches" [Critical,In progress] https://launchpad.net/bugs/390563 rockstar, do you know about the latter one? the lp-code bugtask is in triaged state matsubara, so, there were two issues here, one client side, one server side. The server side one has been fixed on Launchpad. sinzui, all right. where are you keeping track of this work? I'd like to link bugs that might benefit from it to the spec bug 391903 should probably not be critical - a patch and test update needs to land this cycle sometime. Production is fine at the moment. Launchpad bug 391903 in launchpad-code "Scanner user needs more database permissions" [Critical,In progress] https://launchpad.net/bugs/391903 A blueprint. I have not scheduled it since my team may state it requires an infinite number of monkeys to complete stub, is it not critical anymore because the permissions were granted on the production db? I think so. The patch does have to land before next rollout though or that will revert. Does that count as critical? sinzui, right. let me know the URL please stub, matsubara: that should simply be high I'll lower the importance. thanks flacoste and stub rockstar, since it was fixed on LP, could you set the bug as fix released? matsubara: systemic problems are not fixed in critical issues. I am mearly stating that I expect to continue to allocate staff to fix these timeout issues until we have new tools to get masses of users and teams from the db s/bug/bugtask/ sinzui, the oops I brought to you today is not critical. matsubara, I think there are some other things we're trying to track (like the client side issue), but I'll raise it in the standup today. matsubara: So I do not need to fix this this cycle? sinzui, what I'm trying to do is link those bugs to the blueprint, so when the systemic problem is fixed, we can fix the oopses with the new infrastructure (or at least consider those bugs while implementing the new infrastructure) sinzui, I don't think they are critical, since it's a soft time out. I'm bringing the issue to you to keep it on your radar matsubara: I must create a blueprint for this class of problem first [action] sinzui to create a blueprint about the systemic problem in retrieving lots of IPerson and let matsubara know ACTION received: sinzui to create a blueprint about the systemic problem in retrieving lots of IPerson and let matsubara know rockstar, thanks! I think that's all for the oops & critical bugs section thanks everyone [TOPIC] * Operations report (mthaddon/herb/spm) New Topic: * Operations report (mthaddon/herb/spm) herb, ? Since I totally slacked off last week on the OSA report, I'll cover the last two weeks here. 2009-06-24 - Production rollout to r2.2.6. Rollout took longer and caused unforseen downtime. Details can be found in the incident report. 2009-06-26 - Cherry picked r8204 to codehost 2009-06-26 - Cherry picked r8205 to lpnet*, edge* and the scripts server. 2009-06-26 - Cherry picked r8701 and r8703 to lpnet* and (part of) soyuz. Since the 2.2.6 rollout we've seen a slight uptick in load on the app servers and, early on at least, significant load on the code importers. Staging has seen signifcant memory leaks. The app server has often been 5-10GB resident. This is a pretty bug that will clearly need to be resolved before we can push to production. herb: it's because of the storm update, stub thinks he landed a fix today herb: plan is to land this storm update on edge once it clears staging flacoste: I figured. I'd like to see it running on staging for a couple of days without leaks before seeing it on edge. herb: sure cool I'll assign bug 393990 to stub and move to -foundations. Launchpad bug 393990 in launchpad "staging app server using too much memory" [Undecided,New] https://launchpad.net/bugs/393990 matsubara: that's actually a dupe matsubara: that's probably a dupe of 390861 sorry #390861 bug 390861 Launchpad bug 390861 in launchpad-foundations "Appserver memory issues with Storm 0.14" [High,Triaged] https://launchpad.net/bugs/390861 dammit! :) ah, ok. so it's all fine matsubara: bug 390861 well, not fine, but at least it's being tracked :-) thanks herb and flacoste let's move on [TOPIC] * DBA report (stub) New Topic: * DBA report (stub) Staging is now hopefully running a non-leaking version of Storm (0.14 + r290 from lp:storm). Its been up for maybe an hour now with no sign of memory bloat, so it is looking promising. if all goes well, next step is to land this on launchpad/devel for testing on edge. I repaired about 1300 invalid crosslinks between Person and EmailAddress as best I could. Hopefully these were caused by manual updates or since fixed bugs. The other 2.7 million records are fine. Admins or myself should be able to recover any lost permissions of branches if the reclaim account and merge processes don't suffice. garbo-nightly.py is growing detection of this case (code done, tests to go). . question to stub? ok, I think that's all for today then. Thank you all for attending this week's Launchpad Production Meeting. See the channel topic for the location of the logs. stub: is the permissions reclamation process documented? #endmeeting Meeting finished at 10:35. oops, sorry herb no problem thanks matsubara * intellectronica (n=tom@intellectronica.net) has left #launchpad-meeting * henninge (n=henning@e177213189.adsl.alicedsl.de) has left #launchpad-meeting ("Ex-Chat") herb: No - it will depend what the problem is. Most people affected (assuming they are active users) should be able to recover things using their registered email addresses. ok herb: It should be like a forgotten password... * stub crosses fingers heh. got it. matsubara: https://blueprints.edge.launchpad.net/launchpad-registry/+spec/efficient-user-sets sinzui, thanks