tal:content="cache:anonymous, 1 hour"> [00:18] tal:content="cache:public, 5 minutes" tal:omit-tag=""> [00:18] yes, thats two conflicting cache rules in the same file, adjacent. [00:18] is the latter nested in the former? [00:18] why yes, funny you should ask that. [00:18] awesome [00:18] line 215,216,217,218 there [00:22] * james_w waves to NZ [00:24] I thought we had something that injected values into memcache for the home page [00:24] but I cannae find it [00:24] hi james_w [00:25] hi james_w [00:25] lifeless: that sounds like something that would be suspiciously well designed for lp memcache [00:26] bitter bitter [00:27] * james_w now has tarmac updating sourcedeps.conf for config-manager, so that staging can autorollout changes across any branch involved in a deployment [00:28] the next target should be the latency before deployment-manager sees that [00:28] nice [00:28] I would like to drop update-sourcedeps and put LP back to config-manager [00:28] yeah [00:28] since the functionality is basically identical, except that the sysadmins use config-manager :) [00:28] I was pondering about replacing config-manager with bzr-builder the other day [00:29] but I'm not sure there's any benefit [00:29] 6/1 1/2 of the other [00:29] except for having one fewer codebase [00:29] well, neither is a superset of the other [00:29] so I don't think you'd achieve that in the first instance. [00:29] the reason I was thinking of that is that I thought it would be useful to have the "only do it if something is changed" feature of bzr-builder [00:30] ah, so there is something like that in update-sourcedeps [00:30] but talking with web-ops led me to believe that having tarmac update things rather than relying on that is a better way to go [00:30] should be straight forward enough to give config-manager a similar hinting facility [00:30] lifeless: Those memcache rules you quoted aren't necessarily wrong. They could be quite reasonable. [00:30] wgrant: orly [00:31] the only other small benefit I could see is the "manifest" that bzr-builder writes [00:31] lifeless: And no, nothing injects. That was a proposal to remove HTTP access from the appservers. [00:31] wgrant: you mean if the inner one ends short [00:31] that is valid input, so you could deploy exactly to production what was in staging by linking up the output of one to the input of the other [00:31] but we are close enough to that already I think [00:32] wgrant: and even if it ends short, its wrong [00:32] wgrant: you have to have your *longest* cache times at the innermost context. [00:32] lifeless: It may be *misguided*. [00:32] lifeless: But it's perfectly valid. [00:32] lifeless: Why? [00:32] The top-level one caches for an hour for anonymous users. [00:32] Non-anonymous users get lower expiration times. [00:33] anyhow, gones now. [00:33] there are precisely two uses of memcache I'm a little wary of removing, but I'm willing to take the risk. [00:33] I may need to go back and feature flag this change, somehow. [00:33] will see [00:34] The frontpage blogpost one can't really be removed. [00:34] The others can. [00:35] that is one of them [00:35] and it can be [00:35] lol [00:35] Let's not call into a frequently down Wordpress on every RootObject:+index load,l please. [00:38] the other one is the global counts on RootObject:index.html [00:39] aieee pageidblindness RootObject:+help-blueprints for /srv/launchpad.net/production/launchpad-rev-15190/lib/lp/blueprints/help [00:39] lifeless: SELECT MAX(id) :) [00:39] wgrant: they are currently cached, I'm assuming there is some insanity lurking. [00:40] There is. [00:40] wgrant: so, we're meant to be using squid in the DC everywhere [00:40] Which is why you should SELECT MAX(id) [00:40] lifeless: Ha ha ha [00:40] lifeless: We do. [00:40] wgrant: we get sensible headers from this wordpress: [00:40] Last-Modified: Wed, 06 Jun 2012 15:15:54 GMT [00:40] ETag: "3fafd55d87f99a8d01f330c4402a3b75" [00:40] lifeless: Whether it's not broken or actually useful is another quesiton. [00:40] Oh [00:40] That's surprising. [00:40] wgrant: so other than a check with webops that appservers are actually using it [00:40] I'm not concerned. [00:41] it is 37K of html to parse. [00:41] lifeless: We also need to fix it to not crash if it can't retrieve it. [00:41] but we can move the caching into the model rather than template if we want to [00:42] lifeless: We've used this as fault-tolerance in the past, and everything goes to shit if the cache happens to expire while it's down. [00:43] wgrant: since you are here. [00:43] wgrant: I'd like your opinion on the tal:cache in lib/lp/app/templates/base-layout-macros.pt [00:43] AFAICT the entire block is removable as something insane [00:44] but, I'm likely misunderstanding it [00:44] You are completely misunderstanding it [00:44] It's unrelated to memcache; run away [00:44] ^ that memcaches its output [00:45] Nope [00:45] tal:FOO [00:45] The FOO means nothing. [00:45] Only the NS is important. [00:45] Oh, freaking lies. [00:45] lies lies lies. [00:45] Have I mentioned I loath some parts of tal ? [00:45] It just implies a no-op element and removes the need for the NS on attribute names. [00:46] grep caught it [00:46] cause tal:cache was used by folk to setup memcache rules. [00:46] thanks for 'splaining. [00:46] be nice to give it a clearer name. [00:46] np [00:47] my lp:memcache branch will be massive LoC win soon :) [00:48] well, s/massive/enoughtodosomethinginterestingwith/ [00:49] and pushing \o/ [00:52] mwhudson: bug 623199 lies [00:52] <_mup_> Bug #623199: scripts do not establish valid zope participations

< https://launchpad.net/bugs/623199 > [00:52] the 'in progress' part? [00:53] and the assignee I suspect, part and parcel [00:53] unless you are ... [00:53] yes certainly that [00:53] i guess it's a classic of not really specifying a condition of when it can be called done [00:53] as i pointed out early on the title is also a lie, after all [00:53] wgrant: bug 939055 - its alredy mmmmmmmmmm horrible [00:53] <_mup_> Bug #939055: front page blog feed updates are done in-line with requests < https://launchpad.net/bugs/939055 > [00:54] sorry, cat got in there [00:54] lifeless: Horrible but working. [00:54] wgrant: yes, and when the blog is down, and memcache times out, the behaviour we see will be the same [00:54] No. [00:54] lifeless: if you want to retitle it as "timelines are not automatically cleared when a new interaction is set up" then it's back to triaged [00:54] wgrant: you'll need to unpack that. [00:55] lifeless: We'll see it when the blog is down. [00:55] No memcache timed out required. [00:55] Currently a memcache timeout is required. [00:55] wgrant: which is a mild increase in frequency increase [00:55] lifeless: Before it can be removed we need to prevent it from crashing. [00:55] wgrant: a 10 minute outage today has a 1 in 6 chance of showing the same crash. [00:55] lifeless: if you want to retitle it "scripts use interactions which are not suitable for storing interesting things on" then its fix released [00:55] wgrant: so no, we don't 'need' to. [00:56] (and you should file/find a new bug for that first thing) [00:56] lifeless: This means it's impossible to perform any maintenance on the blog without bringing parts of Launchpad down. [00:56] mwhudson: FR it please. [00:56] wgrant: no, it doesn't, because it will still be cached, and we can trivially make that page a 60 minute cache as well. [00:56] wgrant: via a one-line config change to squid. [00:57] Ah good, SPOFing ourselves even more on druzhnaya :) [00:57] lifeless: https://bugs.launchpad.net/launchpad/+bug/623199 [00:57] <_mup_> Bug #623199: there is no way to store interesting data on the participation scripts set up

< https://launchpad.net/bugs/623199 > [00:57] wgrant: vs memcaches non-resilient cluster, no significant difference. [00:57] mwhudson: thanks [00:58] lifeless: Well, the memcached cluster is not an Antarctic base and we haven't had major problems with it in the past. [00:59] wgrant: so put numbers on this; whats the expect change, in % of our OOPS count per month. [01:04] wgrant: did you remove the webservice entity cache stuf? [01:04] lifeless: It's gone from LP, but not from lazr.restful. [01:05] kk [01:06] darrens has confirmed, appservers are using druz for it. [01:08] and we're getting -lots- of hits on it [01:08] wgrant: another thing you've missed; you're assuming the front page is staying in memcache [01:09] last I checked our stats, we have a ridiculously low hit rate, partly due to high evictions. [01:09] allenap: are you really hacking on bug 704585 ? [01:09] <_mup_> Bug #704585: canonical_url performs poorly < https://launchpad.net/bugs/704585 > [01:14] wgrant: bug 618019 [01:14] <_mup_> Bug #618019: storm processing of result sets can be very very slow < https://launchpad.net/bugs/618019 > [01:14] wgrant: just retitled. Thats the one about cache handling and columns etc. [01:15] wgrant: and/or bug 632145 [01:15] <_mup_> Bug #632145: handling of Specification result sets with 3000 rows is slow < https://launchpad.net/bugs/632145 > [01:17] hmm, can't find the bug about series/milestones having caching [01:25] anyone know if there's a standard for publishing structured content in an atom feed? [01:25] hmm, we may have fun :) - 24 / 0 RootObject:index.html [01:25] i.e. for PuSH [01:26] james_w: 'atom' [01:26] for something that isn't author/description/etc. [01:26] description = json.dumps(whatever) perhaps [01:27] james_w: its xml [01:27] james_w: putting json in xml would be fffffugly at best :) [01:28] james_w: however, atom has no DTD or validator [01:28] james_w: so, IIRC, you can just add any keys you want [01:29] http://tools.ietf.org/html/rfc4287#section-6 [01:30] james_w: ^ [01:30] james_w: are you looking at PSHB ? [01:35] mwhudson: https://code.launchpad.net/~lifeless/launchpad/memcache/+merge/109551 if yo ufeel like a treat. [01:36] lifeless, yes [01:37] james_w: I'm very keen on PSHB, FWIW. [01:37] lifeless, the next question is how to convince a library to add arbitrary content :-) [01:37] lifeless, I know, the two are related :-) [01:37] james_w: :) === lifeless changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2 [03:39] james_w: did your oops-tools patch fail ? [03:39] james_w: or we just haven't deployed. [03:39] lifeless, the branding one? [03:40] yes [03:40] lifeless, it's waiting on tarmac or something [03:47] james_w: webops run that, and don't want the MP's, so a ping on -ops is the thing (which I've just done) [03:48] ok [03:54] can has revu https://code.launchpad.net/~lifeless/launchpad/bug-1011390/+merge/109559 [04:06] diff updating seems stuck there [04:08] I see a diff [04:10] r=stub [04:10] I saw a diff. I also saw the yellow diff-is-updating blurb. Odd since there is only one unmerged revision? [04:12] huh, yes [04:12] that is indeed odd [04:12] I only pushed to it the once [04:12] stub: this may be more interesting https://code.launchpad.net/~lifeless/launchpad/memcache/+merge/109551 [04:12] stub: could you ec2-land the former branch? Still on my TODO is fixing my landing environment. [04:13] haha... when I move upstairs, yes :) [04:13] stub: no rush [04:13] stub: have a good weekend ? [04:13] good enough ;) [04:14] brb [04:14] Did sod all besides a movie. [04:16] nice [04:16] I'm finally, as of late sunday, feeling human again [04:16] small bit of sniffles is all that remains [04:16] of course, cynthia is now teething again and didn't sleep at all last night >< [04:16] * lifeless is spaced out [04:16] huh... I also see just 'updating diff' on that memcache mp [07:30] good morning [08:17] lifeless: No, I'm not. I've set it back to triaged. === almaisan-away is now known as al-maisan [08:25] Review of https://code.launchpad.net/~jml/launchpad/validate-ppa-owner/+merge/109529 sought. [08:27] also, how can I tell when my db patch has been deployed? [08:28] Watch http://lpqateam.canonical.com/qa-reports/deployment-db-stable.html; also IME one of the .au cabal will often tell you [08:28] You can also watch https://wiki.canonical.com/InformationInfrastructure/OSA/LaunchpadProductionStatus [08:29] cjwatson: thanks. [08:31] cjwatson: how did you qa your db patch? [08:33] hello all, I have a small problema with a django app that is using launchpad lib to get user info, it gives an HTTPError code 401, saying the the token has expired, does anyone have an idea on how to this could be fixed? bug is #1010455 (repeating question from #launchpad channel) [08:33] <_mup_> Bug #1010455: Patchmetric Login Token Expired < https://launchpad.net/bugs/1010455 > [08:35] jml: ran test suite on corresponding code branch with db patch both unapplied and applied; asked on -ops for somebody to tell me how long the db patch took to apply on (qa)staging so that I could ensure it was within the time limit [08:36] cjwatson: ok. thanks. [08:37] (which looks like /srv/launchpad.net-logs/staging/sourcherry/*-staging_restore.log on carob) === jamestunnicliff_ is now known as jamestunnicliffe [10:05] LP's permission system :( [10:21] I can figure out how to allow a new group of people the ability to *create* private PPAs, but I can't figure out how to let them *set* private. [10:23] Hmm. Hmm. === al-maisan is now known as almaisan-away [10:25] jml: do you need any branches now made private if you do just shout and I can do it for you. [10:26] czajkowski: I think I'm OK thanks. === almaisan-away is now known as al-maisan === matsubara is now known as matsubara-lunch [10:38] morning [10:39] ivorykr8: howdy, welcome to the squad === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugs: 3.47*10^2 [12:09] ivorykr8, welcome. don't believe allenap, we're bots. [12:12] gary_poster: that's just what a non-bot would say! [12:12] rick_h, my brother always lies. I always tell the truth. === matsubara-lunch is now known as matsubara [12:23] oh hey [12:23] on call reviewers! [12:24] anyone recall if there's a way to python -m module:function ? [12:24] I can get the module part, but not the function in the module [12:24] benji: https://code.launchpad.net/~jml/launchpad/validate-ppa-owner/+merge/109529 is the first of three patches that needs review. [12:24] rick_h: python -c 'import module; module.function()' [12:25] jml: I'll take a look. [12:26] benji: thanks. [12:41] jml: thanks === jam1 is now known as jam [13:08] benji: sinzui has just approved that branch. https://code.launchpad.net/~jml/launchpad/p3a-private-team/+merge/109600 is the next one in the series. [13:09] jml: ok === fjlacoste changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | Welcome our new intern: ivorykr8 | On call reviewer: benji | Firefighting: - | Critical bugs: 3.47*10^2 [13:38] ivorykr8: welcome! [13:39] 'morning fjlacoste [13:39] hi ivorykr8 === fjlacoste is now known as flacoste [13:40] hi jelmer [13:41] Hi ivorykr8 and welcome to the team! [14:02] ivorykr8, welcome! Here's the link for the stand-up: https://plus.google.com/hangouts/_/4b599a50a7ebb329230ced7d9caef1ba95835bfc?authuser=0&hl=en [14:02] adeuring, likewise ^^ === al-maisan is now known as almaisan-away [14:50] Hello! If I can see a private bug, I had thought that meant I can edit its privacy. But I've encountered a crasher where that's not the case. Is there a way to find out why I can't edit the privacy? [14:52] (this is bug 1011293) [14:53] No bug bot? :( https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1011293 [15:05] welcome ivorykr8 [15:18] ivorykr8: how are you doing on day 1 anything we can help you with ? [15:21] well actually no i just try to get myself into python :) [15:32] https://code.launchpad.net/~jml/launchpad/remove-top-tests/+merge/109664 up for review [15:32] (Heals 477 lines of damage) [15:35] benji: Thanks for your review on https://code.launchpad.net/~cjwatson/launchpad/pocket-permissions/+merge/109192; can you "Status: Approved" and I'll land it? [15:35] cjwatson: sure [15:36] jml, delete it in the other branch too and score double! [15:37] james_w: well, ISTR objecting when it was first added. [15:45] I assume that was before testr slowest was added? [16:37] james_w: yeah, but it was after subunit reports were available from bin/test, I think. [17:50] morning everyone [18:01] is there a LoC score board? [18:01] other than ohlo, no. [18:02] and cjwatsons thing [18:03] ta [18:04] * jml has been mucking around with dmg [18:05] benji: hi [18:05] hi lifeless [18:05] benji: if you're still on the review hook, perhaps you can do me a related favour [18:05] 05:59 < lifeless> anyone around to run an ec2 test command for me? Will get my environment fixed soon, I swear. [18:05] 05:59 < lifeless> https://code.launchpad.net/~lifeless/launchpad/memcache/+merge/109551 [18:05] (I asked in the wrong channel initially :P) [18:07] lifeless: Instance starting. I'll give you the URL when it presents itself. [18:07] benji: oh doh [18:07] benji: I mean 'ec2 land' [18:07] not ec2 test. [18:07] heh [18:07] ok, restarting [18:07] * lifeless stabs his lying fingers. [18:08] heh [18:08] benji: thanks [18:10] g'night === jcsackett_ is now known as jcsackett [18:10] night jml === matsubara is now known as matsubara-afk [21:39] benji: could you try again, if you're still around ? [21:39] benji: I've pushed a fix [21:50] wallyworld_, StevenK, wgrant: i don't think i'm making standup--i've been feeling progressively iller as the afternoon has worn on and i'm at the point where i just need to crash. [21:50] s/iller/more ill/ === salgado is now known as salgado-afk [22:01] jcsackett: sorry to hear that, get well soon [22:22] lifeless: I was AFK. Running ec2 land for you now. [22:32] benji: thanks! [22:45] wgrant: Brian's branch also needs QA. [22:45] And lifeless' r15388 [22:46] StevenK: Yes, but they're rather simple. [22:46] * StevenK looks for an open team on qas to abuse [22:53] StevenK: mine doesn't, just qa-ok it; no code changes [22:53] config default value change + increased test coverage. [22:56] wgrant: So my change sort of works. If you select/type an open team and hit Subscribe, the form submits and dumps you back to Branch:+index with no feedback, but they are not subscribed. [23:00] StevenK: So the form has no error handling? [23:01] wgrant: My code calls setFieldError(), so I'm not sure why that doesn't fire. [23:07] StevenK: Simply setting a fielderror won't do much if the form isn't rendered. [23:07] StevenK: You probably want to not set next_url in that case [23:07] So it doesn't redirect away [23:07] Normally the validation is done in a validate method, not the action itself. [23:09] wgrant: So I think the code may need a little more polish -- use a validate method on Branch:+subscribe like you say, and probably change the JS popup if the branch is private and the reviewer is an open team when proposing an MP. [23:09] validate may be less appropriate here. [23:10] LBYL is perhaps not a good idea. [23:11] wgrant: Oh? What do you suggest then? A notification that "so-and-so not subscribed, this branch is private and they are an open/delegated team." ? [23:11] Personally I would alter the JS popup to not change anything, and just tell you that you're doing something stupid. Since it should become rare that people don't have access. [23:11] StevenK: I'd probably have the action catch the exception and display an error. [23:11] Like you do now, except in a way that actually works. [23:12] Haha [23:12] I thought setFieldError() would work :-( [23:12] It sets a field error. [23:14] Creating an MP with an open team as a reviwer has them pop up as the reviewer, but they don't get subscribed. [23:17] wallyworld_, wgrant: Parramatta got 90mm of rain yesterday. [23:17] is that all? [23:19] Hah [23:51] wgrant: So I think this is qa-ok for now, but I will come back to it after the DB patch o' doom. [23:53] StevenK: Sounds good. [23:53] Seems like you have a tonne of missing test coverage, thoguh. [23:53] A test for the field error is there, and it passed. :-(