| StevenK | OMG, actual sun. | 01:20 |
|---|---|---|
| nigelb | heh | 01:22 |
| nigelb | I thought you guys had plenty of sun. oh wait, because winter? | 01:22 |
| wgrant | Because winter and because Sydney. | 01:23 |
| nigelb | Ah! | 01:23 |
| StevenK | nigelb: The suburb I live in got 90mm of rain yesterday. | 01:25 |
| nigelb | Woah. | 01:25 |
| StevenK | wgrant: We need at least two DB patches. We need to drop NOT NULL from private and transitively_private | 01:28 |
| wgrant | StevenK: False. They both have defaults. | 01:32 |
| StevenK | Ah | 01:34 |
| StevenK | Right, so they get set to false irrespectively to information_type and they can just get dumped. | 01:35 |
| wgrant | StevenK: transitively_private default to true, but yes. | 01:36 |
| wgrant | StevenK: We can just stop setting them and they will default to relatively sensible things that nothing will see anyway. | 01:36 |
| wgrant | Then we can drop them. | 01:36 |
| StevenK | wgrant: You were talking about bug_build_access_cache in 16-0 that I should look at? | 02:02 |
| wgrant | StevenK: That sort of thing, yes. | 02:07 |
| lifeless | wgrant: ping (LEP, impl notes) | 03:32 |
| lifeless | ugh | 03:37 |
| lifeless | this post-merge-dif-nuking really is disruptive. | 03:37 |
| lifeless | https://code.launchpad.net/~lifeless/launchpad/memcache/+merge/109551 | 03:37 |
| StevenK | lifeless: It doesn't even look like that branch has been scanned. | 04:32 |
| lifeless | indeed | 04:36 |
| lifeless | wedged-is-U | 04:36 |
| lifeless | S | 04:36 |
| StevenK | lifeless: bzr push -r -2 ... ? | 04:39 |
| StevenK | lifeless: I approve of +49/-1182 | 04:50 |
| StevenK | wgrant: Am I on the right track? http://pastebin.ubuntu.com/1036633/ | 05:00 |
| lifeless | StevenK: that thing is landed :> | 05:14 |
| lifeless | garyposter: I have checkmarkified https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess#preview | 05:14 |
| lifeless | jml: I'd like to know if https://checkmarkable.com/team/sthederj/checklist/1263/view would have helped your confusion around db schema qa etc the other day. | 05:14 |
| StevenK | lifeless: Hmmm, memcache for garbo is useful. If we had some other way to record stuff between runs it could die a horrible death | 06:03 |
| * StevenK stabs the branch scanner | 06:23 | |
| stub | StevenK: Do you mean, like, some sort of persistent database? | 06:23 |
| StevenK | stub: Haha | 06:24 |
| stub | Its a pretty bad fit for garbo. If that is the last use of it, we should replace it with something suitable. | 06:24 |
| stub | Keep the IMemcache interface for lazyness | 06:24 |
| StevenK | stub: I think it's the last use. | 06:25 |
| StevenK | And only a few jobs use it | 06:25 |
| StevenK | One job, in fact. | 06:25 |
| stub | And it could be replaced with sqlite easily enough or even something less like a hack | 06:25 |
| StevenK | wallyworld_: Do you have a sec to look over https://code.launchpad.net/~stevenk/launchpad/drop-set-spph-packageupload/+merge/109776 ? | 06:26 |
| nigelb | woah, LP has a new intern? | 06:27 |
| nigelb | You guys are going to break him, aren't you? ;-) | 06:27 |
| wallyworld_ | StevenK: a sec yes, i'm about to go see aus vs japan :-) | 06:27 |
| StevenK | wallyworld_: It's +1/-133, so it should be very quick | 06:27 |
| nigelb | wallyworld_: rugby? | 06:27 |
| StevenK | Soccer | 06:27 |
| StevenK | World Cup | 06:27 |
| nigelb | wat. | 06:27 |
| nigelb | Soccer World Cup? | 06:28 |
| wallyworld_ | nigelb: football | 06:28 |
| nigelb | o_O | 06:28 |
| wallyworld_ | world cup qualifier | 06:28 |
| nigelb | aha | 06:28 |
| nigelb | that makes better sense | 06:28 |
| StevenK | We are going to lose horribly | 06:28 |
| wallyworld_ | yep :-( | 06:28 |
| nigelb | I was following Eurocup and couldn't believe there was world cup going on. | 06:28 |
| wallyworld_ | StevenK: r=me | 06:29 |
| StevenK | wallyworld_: Thanks. Go and enjoy the soccer. | 06:29 |
| wallyworld_ | will do. hope we at least make a decent game of it | 06:30 |
| lifeless | StevenK: two jobs when I looked in trunk | 06:34 |
| StevenK | lifeless: Yup, I just removed one in the MP wallyworld_ reviewed. | 06:38 |
| lifeless | StevenK: ah, kk. | 06:46 |
| lifeless | we could do a persistent transactional k:v store in the DB | 06:46 |
| lifeless | or we could grab redis or something with persistent backing and use that. | 06:46 |
| lifeless | memcache is fine I think today. | 06:46 |
| lifeless | stub: sqlite in production would be more, not less of a hack :) | 06:47 |
| stub | lifeless: yer, I'm not suggesting it is a briliant idea. just that there are alternatives. | 06:48 |
| stub | There is a new hstore datatype in PG 9.1 for k,v stuff. | 06:49 |
| stub | And json to match the existing xml datatype | 06:49 |
| === matsubara_ is now known as matsubara | ||
| wgrant | lifeless: Hi, just added them. https://dev.launchpad.net/DisklessArchives and https://dev.launchpad.net/LEP/DisklessArchives | 07:36 |
| lifeless | I'll do an edit pass and then let elmo etc know | 07:40 |
| lifeless | wgrant: we may want two leps; a horizontal scaling one covering the uploader bug etc, and this one. *may* | 07:44 |
| wgrant | lifeless: Possibly, yes. | 07:44 |
| wgrant | But we also need *something* for the whole picture, I think. | 07:45 |
| lifeless | Can't fault your logic | 07:47 |
| lifeless | uhm, we'll see. I'm applying humanizing to this doc just now :) | 07:48 |
| lifeless | thank you for putting them together. | 07:48 |
| lifeless | wgrant: you've let a lot of implementation detail leak into the LEP (I mention this so you don't think I'm crazy for deleting it). I'll ensure it survives somewhere. | 07:49 |
| wgrant | lifeless: Probably. | 07:51 |
| adeuring | good mornin | 07:53 |
| lifeless | wgrant: could you check (e.g. on dogfood, or give me a query) the number of unique people uploading to ppa.l.n ? | 07:57 |
| jelmer | g'morning adeuring | 07:57 |
| adeuring | hi jelmer | 07:57 |
| wgrant | lifeless: SELECTing. | 07:59 |
| === almaisan-away is now known as al-maisan | ||
| lifeless | wgrant: https://dev.launchpad.net/LEP/DisklessArchives edited, please check I didn't trash your intent :) | 08:28 |
| wgrant | lifeless: Looks reasonable. | 08:31 |
| wgrant | Thanks. | 08:31 |
| === jamestunnicliff_ is now known as jamestunnicliffe | ||
| lifeless | wgrant: still around ? | 09:18 |
| wgrant | lifeless: A little. | 09:18 |
| wgrant | lifeless: 'sup? | 09:19 |
| lifeless | so you claim external acls are cached on the full request path. | 09:20 |
| lifeless | But | 09:20 |
| lifeless | makeExternalAclKey | 09:20 |
| lifeless | claims otherwise | 09:20 |
| lifeless | I want to check why you say that before I delete it as wrong :) | 09:20 |
| lifeless | wgrant: ^ | 09:21 |
| wgrant | lifeless: makeExternalAclKey? Is that some Squid thing? | 09:22 |
| lifeless | yes | 09:22 |
| wgrant | lifeless: Squid can't know that we only care about the first two segments of the path. | 09:23 |
| lifeless | its the thing that makes the helper cache key from the helper parameter format string | 09:23 |
| lifeless | wgrant: thats what the third helper is for. | 09:23 |
| lifeless | wgrant: it does that, trivially, and tags the request. | 09:23 |
| wgrant | Well, Squid itself doesn't cache it. One of the helpers does, if there are two. | 09:23 |
| wgrant | Does the acl helper get the tags? | 09:23 |
| wgrant | The rewrite helper doesn't. | 09:23 |
| lifeless | so, there are three helpers | 09:25 |
| lifeless | mapper | 09:25 |
| lifeless | it takes url, returns ppa string, does no DB lookup at all. Purely local. | 09:25 |
| lifeless | it is cached by squid on full url. | 09:25 |
| lifeless | authenticator | 09:26 |
| wgrant | That's the ideal situation. | 09:26 |
| lifeless | it takes the auth header + the ppa tag, does DB lookup (via webservice). | 09:26 |
| lifeless | its cache by squid on the auth header value + the ppa tag value. | 09:26 |
| wgrant | But I didn't see a way for the mapper to execute before the others and tag the request in a way they could see it. | 09:26 |
| lifeless | you use it in an acl earlier. | 09:27 |
| lifeless | we may need four helpers in fact, we need to detect ppa.l.n requests to private ppas. | 09:27 |
| wgrant | Ahh. There's an %EXT_TAG new in 3.2 | 09:28 |
| lifeless | the mapper always succeeds, and you say http_access deny !mapper | 09:28 |
| wgrant | (which isn't in Ubuntu) | 09:28 |
| lifeless | or some such. | 09:28 |
| lifeless | just %TAG should be fine, no ? | 09:28 |
| wgrant | Is that a thing? | 09:28 |
| lifeless | ah no | 09:29 |
| lifeless | misread the code. | 09:29 |
| lifeless | So we need that ported, or to run 3.2. | 09:29 |
| lifeless | noting. | 09:29 |
| wgrant | "%EXT_TAG tag= value returned by previous external ACL calls. Tag may not be altered once set." | 09:29 |
| wgrant | lifeless: So we can't stack tags. | 09:29 |
| === gmb changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | Welcome our new intern: ivorykr8 | On call reviewer: gmb | Firefighting: - | Critical bugs: 3.47*10^2 | ||
| wgrant | lifeless: I was handling public-on-private by an arg on the the librarian mapper func, but something nicer might be better. | 09:30 |
| lifeless | wgrant: oh, two rewriters? | 09:31 |
| wgrant | lifeless: Or just pass the hostname in. | 09:32 |
| wgrant | But two rewriters might be cleaner. | 09:32 |
| lifeless | well, a public and private ppa may map to the same file | 09:32 |
| lifeless | I propose just having one rewriter that doesn't care about public/private, and do the public/private check separately. | 09:33 |
| lifeless | for public requests we check the ppa is public, for private ones we check its authed and their creds match | 09:33 |
| wgrant | I guess the extra public roundtrip doesn't suck too much if we're using a separate API service that isn't LP. | 09:33 |
| jml | lifeless: | 09:34 |
| jml | lifeless: that's the checklist at the top of the process page, but with some detailed notes | 09:34 |
| jml | lifeless: I made edits to the wiki page as I went, correcting sources of my confusion or uncertainty | 09:35 |
| wgrant | lifeless: So we just have a separate verify_public external_acl_type? | 09:35 |
| wgrant | Which uses a separate helper | 09:35 |
| lifeless | jml: it is, but its also a stateful checklist so you can work through it as yor patch progresses. | 09:36 |
| lifeless | jml: bayme thats not helpful. | 09:36 |
| lifeless | wgrant: yes, and use squid acl rules to route to one or tother. | 09:37 |
| wgrant | lifeless: Right, if you look at my sample config it's trivial to do. | 09:37 |
| jml | lifeless: that might help. I couldn't say. I don't feel I lost track of where I was at any point, despite it being a multi-day process | 09:37 |
| lifeless | wgrant: we're going to want a small patch to squid | 09:38 |
| lifeless | wgrant: to let the helper turn off caching for failures. | 09:38 |
| jml | incidentally, I made this: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AsE2-aW-RE8adG5vbW1nN3dJV0o0WUVKSElFRE9UUFE#gid=0 | 09:38 |
| wgrant | lifeless: negative_ttl=0? | 09:38 |
| lifeless | jml: we're running an experiment with checkmarkable, if you want to help that you could use it next time. | 09:38 |
| jml | lifeless: ok. | 09:39 |
| lifeless | wgrant: oh, that will do fine :) | 09:39 |
| lifeless | wgrant: I forgots. | 09:39 |
| wgrant | lifeless: external_acl_type has it, not sure if url_rewrite_helper does | 09:39 |
| wgrant | But I assume so | 09:39 |
| jml | lifeless: I can't say it's grabbed me. | 09:39 |
| * jml *sighs* | 09:39 | |
| lifeless | jml: its trying hard :) | 09:39 |
| jml | I'm just a little sick of rattling my tin cup every time I want a review. | 09:39 |
| * jml drags it out again | 09:39 | |
| jml | Alms for the poor? https://code.launchpad.net/~jml/launchpad/remove-top-tests/+merge/109664 | 09:39 |
| wgrant | url_rewrite_program doesn't have any such config. Probably somewhere else determines it. | 09:40 |
| lifeless | gmb: ^ | 09:40 |
| jml | Spare a penny for poor ex-leper? https://code.launchpad.net/~jml/lp-dev-utils/apply-top-tests-fixes/+merge/109665 | 09:40 |
| StevenK | jml: remove-top-tests r=me | 09:41 |
| lifeless | wgrant: rewriter gets user= passed to it, if we want it | 09:41 |
| gmb | jml, Looking now. | 09:41 |
| lifeless | wgrant: src/redirect.cc redirectStart(ClientHttpRequest * http, RH * handler, void *data) | 09:42 |
| StevenK | gmb: I grabbed the LP one already | 09:42 |
| gmb | StevenK, Ok. | 09:42 |
| lifeless | wgrant: I'm not sure the rewriter has caching; we may need a aggressive cache layer just for it. | 09:43 |
| gmb | ... the worrying implication, carrying on from jml's script, is that StevenK is somehow the messiah. This has far too many unpleasant implications for me, so I'm just going to look at the lp-dev-utils branch and STFU. | 09:43 |
| wgrant | lifeless: I don't think user= is useful.extuser= might be. | 09:43 |
| wgrant | lifeless: Right, we'd basically need completely custom caching for the rewriter anyway. | 09:43 |
| lifeless | wgrant: rephrase, I'm reasonably sure it doesn't have caching. | 09:43 |
| lifeless | wgrant: custom, how so ? | 09:43 |
| wgrant | lifeless: As I detail in my musings on the different cache coherency constraints. | 09:43 |
| wgrant | lifeless: pool/ should cache forever and then some. | 09:43 |
| wgrant | dists/ should not | 09:43 |
| lifeless | wgrant: you forgot that the cache keys are based on the rewrite value | 09:43 |
| StevenK | gmb: Unpleasant for you | 09:43 |
| lifeless | wgrant: unless you disproved that. | 09:43 |
| StevenK | ? What about ME!? | 09:43 |
| wgrant | lifeless: I mean the lookups. | 09:44 |
| gmb | StevenK, You're the one that's going to end up nailed to a tree. | 09:44 |
| jml | gmb: he's not the messiah. he's a very naughty boy. | 09:44 |
| wgrant | lifeless: Pool file rewrites never have to hit the DB ever again. | 09:44 |
| StevenK | jml: I was waiting for that. | 09:44 |
| wgrant | lifeless: Because they never change./ | 09:44 |
| lifeless | wgrant: ah! That was entirely unclear. | 09:44 |
| jml | StevenK: thanks for the review. | 09:44 |
| * lifeless reedits. | 09:44 | |
| gmb | jml, I'm so, so sad to say that I didn't actually see that coming :) | 09:44 |
| StevenK | Hahaha | 09:44 |
| czajkowski | gmb: you need to get out more | 09:45 |
| gmb | jml, Anyroad up, your lp-dev-utils branch is approved. Want me to merge it for you? | 09:45 |
| wgrant | lifeless: "Caching of archive path to librarian URL rewrites is a bit of an unresolved issue. While pool/ lookups should be cachable forever without requiring revalidation" | 09:45 |
| wgrant | lifeless: Pretty explicit :) | 09:45 |
| jml | gmb: yes please. I'll land the removal branch. | 09:45 |
| gmb | czajkowski, This is not, in fact, something with which I would disagree. | 09:45 |
| lifeless | wgrant: and yes, entirely unclear :) | 09:45 |
| lifeless | s/yes/yet/ | 09:45 |
| wgrant | lifeless: I should have mentioned, though, that we'd confirmed Squid cached the content based on the post-rewrite URL | 09:46 |
| wgrant | lifeless: Howso? :) | 09:46 |
| lifeless | wgrant: I had no sleep sunday night. *anything* may fail to be unclear. | 09:46 |
| wgrant | Heh | 09:46 |
| wgrant | May fail to be unclear? | 09:46 |
| wgrant | Heh | 09:46 |
| wgrant | Anyway, I await your edits. | 09:46 |
| gmb | czajkowski, Still, only 1 week and I get to catch the bollocks o'clock train to our shiny new HQ. | 09:46 |
| czajkowski | gmb: whoo shall see you there with bells on | 09:46 |
| gmb | \0/ | 09:47 |
| lifeless | wgrant: soon, I think. | 09:47 |
| gmb | jml, Merged and pushed. | 09:48 |
| lifeless | wgrant: I think we want memcache in there. | 09:49 |
| lifeless | wgrant: if you disagree, I'll step you through it. | 09:49 |
| lifeless | wgrant: either that, or we make the mapping step so lightweight we don't need a cache at all. | 09:50 |
| wgrant | lifeless: memcache is probably a good place to cache this, yes. | 09:50 |
| lifeless | wgrant: I haven't gotten into the schema implications of that as yet. | 09:50 |
| wgrant | Hm? | 09:50 |
| wgrant | I deliberately left the caching mechanism unspecified. | 09:50 |
| wgrant | memcached may well be a good option. | 09:50 |
| wgrant | Not sure what you mean by schema implementations. | 09:51 |
| wgrant | implications | 09:51 |
| lifeless | well, what does it take to make url->librarian url mapping take 3ms | 09:53 |
| lifeless | or, lets be generous, 5. | 09:53 |
| wgrant | With a bit of work the DB can answer it is about 2-3ms. | 09:53 |
| wgrant | s/is/in/ | 09:53 |
| wgrant | But we should cache it to avoid hitting it too often. | 09:54 |
| jml | gmb: thanks. | 09:54 |
| wgrant | If we use something shared like memcache we can even have the publisher shootdown the index caches. | 09:54 |
| lifeless | wgrant: well, at 3K rps, we're looking at 9 seconds worth of load/second. | 09:54 |
| wgrant | Rather than revalidating every time. | 09:54 |
| wgrant | Or having a TTL of like 5s. | 09:54 |
| lifeless | so we'd need 9 cores at peak. | 09:54 |
| wgrant | We can easily take that, but let's not. | 09:55 |
| lifeless | and 3 at normal, which we can trivially do. | 09:55 |
| lifeless | wgrant: lets also avoid writing something we don't need :). I am going to call it out, but also let it be a thing to test and validate, not blindly do. | 09:55 |
| wgrant | That's true. | 09:56 |
| jml | it looks like the database rollouts have been blocked for a few days on a non-QAd bug: http://launchpad.net/bugs/1007333 | 09:56 |
| _mup_ | Bug #1007333: update_database_disk_utilization fails with GIN indexes <qa-needstesting> <Launchpad itself:Fix Committed by stub> < https://launchpad.net/bugs/1007333 > | 09:56 |
| jml | anything I can do to push that along? | 09:56 |
| * jml confesses to knowing nothing as yet about GIN | 09:56 | |
| wgrant | jml: Not blocked for a few days. | 09:58 |
| wgrant | Just that we have other things to do tonight, and .au wasn't here yesterday. | 09:58 |
| jml | wgrant: perhaps I'm misreading lpqateam and the bug report, but it says it was marked as needing QA on Jun 1 | 09:58 |
| wgrant | THat's possible -- we've had a lot of backlog to get through. | 09:59 |
| jml | ok. | 09:59 |
| lifeless | wgrant: what do you mean by 'migration path for PPAs' ? | 10:02 |
| lifeless | wgrant: do you mean 'we need to be able to bring up and validate the new environment before breaking what works on germanium? | 10:02 |
| stub1 | It was also a two part landing which would have confused things. | 10:02 |
| stub1 | Second landing didn't happen until Friday? | 10:02 |
| * lifeless assumes he does | 10:03 | |
| wgrant | lifeless: We probably want the ability to run both concurrently for a time, but also we need to be able to migrate to the new one. | 10:03 |
| wgrant | Sorry, distracted by pgbouncer :) | 10:03 |
| lifeless | wgrant: what does that mean though ? | 10:03 |
| lifeless | wgrant: we have two sets of boxes | 10:03 |
| wgrant | lifeless: eg. we need to load all the Packages and Sources and everything into the DB. | 10:03 |
| wgrant | lifeless: And keep them up to date. | 10:03 |
| wgrant | Without taking down PPA publishing for a day. | 10:04 |
| lifeless | wgrant: I don't think we do :) | 10:04 |
| stub1 | qa-ok since staging still works | 10:04 |
| wgrant | Oh? | 10:04 |
| wgrant | lifeless: What is your cunning plan? | 10:04 |
| lifeless | wgrant: If we bring up the new system, and run a 'garbo' job across it to regenerate everything, filling in the missing data, what is the impact on germanium | 10:05 |
| wgrant | lifeless: The garbo job will take more than 5 minutes. | 10:05 |
| lifeless | wgrant: so... | 10:05 |
| wgrant | lifeless: So there won't be holes any more, but stuff will be out of date. | 10:05 |
| lifeless | wgrant: we make the existing publisher make holes. | 10:05 |
| wgrant | lifeless: So the publisher knows about the new DB structures, but only to shoot them in the head? | 10:06 |
| lifeless | its a thought | 10:06 |
| wgrant | Perhaps. | 10:06 |
| lifeless | I don't want to make publishing on germanium *slower* | 10:06 |
| lifeless | that scares me, for hopefully obvious reasons. | 10:06 |
| wgrant | That's a reasonable point. | 10:06 |
| lifeless | so my proposal is to bring up a parallel structure | 10:06 |
| wgrant | But the extra load should be minimal. | 10:06 |
| lifeless | and teach it to cope with germanium doing its thing | 10:06 |
| lifeless | but ignore that germanium did its thing, or detect stale, or something. | 10:07 |
| wgrant | I think that's probably more work. | 10:07 |
| wgrant | But it is indeed a reasonable thought. | 10:07 |
| lifeless | anyhow, now I know what you mean, I can clarify. | 10:07 |
| wgrant | Great. | 10:08 |
| jml | any tips on how to use the LP web ui when it's running within an LXC container? | 10:17 |
| jml | I'm guessing I should just copy /etc/hosts but set it to the lxc instance's ip | 10:17 |
| wgrant | jml: https://dev.launchpad.net/Running/LXC | 10:19 |
| wgrant | Step 10 is https://dev.launchpad.net/Running/RemoteAccess | 10:19 |
| jml | wgrant: thanks. | 10:19 |
| jml | buh wuh | 10:20 |
| jml | apache2 isn't installed? | 10:21 |
| wgrant | That sounds quite extraordinary. | 10:21 |
| wgrant | Sure you ran rocketfuel-setup? | 10:21 |
| wgrant | Is launchpad-developer-dependencies installed? | 10:21 |
| jml | In order: Yes it does. I think I did but I am not certain. Yes. | 10:22 |
| jml | observe: http://paste.ubuntu.com/1036945/ | 10:23 |
| wgrant | Oh right, rocketfuel-setup installs apache separately later on. | 10:23 |
| wgrant | Perhaps it died early and you failed to notice? | 10:23 |
| wgrant | REQUIRED_PACKAGES="launchpad-developer-dependencies apache2 apache2-mpm-worker libapache2-mod-wsgi" | 10:24 |
| wgrant | for pkg in $REQUIRED_PACKAGES; do do_install; | 10:24 |
| wgrant | done | 10:24 |
| jml | heh. | 10:26 |
| jml | wow. | 10:26 |
| wgrant | jml: Re. bug #1011611 I wasn't saying it was reasonable, just that it might be helpful for diagnosis. | 10:26 |
| _mup_ | Bug #1011611: Not possible to file embargoed security bug <bugs> <disclosure> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1011611 > | 10:26 |
| wgrant | ? | 10:26 |
| wgrant | wow? | 10:26 |
| jml | it's like dependencies, but in shell. | 10:27 |
| wgrant | Yeah | 10:27 |
| wgrant | Pretty awesome. | 10:27 |
| wgrant | We don't need no packaging system. | 10:27 |
| nigelb | ... | 10:28 |
| jml | wgrant: (have added this to the bug report) To clarify: clicking on "Public" brings up the chooser in my browser (Chrome) and from there I can change it and submit. I would never have thought to click on it, since there's absolutely no indication in Chrome that it's anything other than a declaration of fact (This bug will be Public). | 10:28 |
| wgrant | jml: Yeah. | 10:29 |
| wgrant | If you mouseover it it gets an underline, but that's it. | 10:29 |
| wgrant | in Firefox it has a drunken exclamation mark. | 10:29 |
| jml | :\ | 10:30 |
| jml | I wonder if there's a more declarative way to say "LP needs these apache modules enabled in order to run" | 10:32 |
| wgrant | I don't believe so. | 10:33 |
| jml | yay running LP | 10:35 |
| wgrant | But can you browse to it? | 10:35 |
| jml | (maybe I'll need to do this again next time I lxc-start?) | 10:35 |
| wgrant | Need to do what? | 10:35 |
| wgrant | The Apache setup is one-off | 10:35 |
| wgrant | Running make run or make start needs to be done every time. | 10:36 |
| jml | wgrant: install apache, enable 5 modules etc. | 10:36 |
| jml | these virtual machines confuse me a little. one of the ones I use resets to a template whenever I use it. | 10:36 |
| wgrant | lxc-start shouldn't. | 10:37 |
| wgrant | lxc-start-ephemeral is the ephemeral variant. | 10:37 |
| lifeless | wgrant: so | 10:37 |
| * jml decides that the only sane thing to do is to eat the last of the Wensleydale. | 10:37 | |
| lifeless | wgrant: primary archive + diskless | 10:37 |
| wgrant | lifeless: lalalalala | 10:38 |
| lifeless | wgrant: I just wrote this: | 10:38 |
| lifeless | split the work in these scripts between on-disk logic and non-disk logic, and migrate the non-disk logic component off of germanium early in the development process, reducing its current load, and giving a single source of logic for the new schema as it comes of age. | 10:38 |
| lifeless | wgrant: how would that interact with primary archive - if we did this, would it *interfere* with it. | 10:38 |
| wgrant | lifeless: It'd mean redesigning the primary archive publisher. | 10:39 |
| lifeless | wgrant: e.g. I'm thinking the first stage would generate jobs to do the spooling to disk etc | 10:39 |
| wgrant | Well, that could work. | 10:39 |
| lifeless | wgrant: because its still apt-ftparchive ? | 10:39 |
| wgrant | lifeless: Right, we can't generate primary archive indices outside the actual on-disk archive. | 10:39 |
| wgrant | lifeless: And because we need to maintain the on-disk archive we need a queue of disk files to publish. | 10:39 |
| lifeless | wgrant: so, we'd need a kludge for the primary archive, to not generate indices upfront, but the rest of the work could be partitioned sanely ? | 10:40 |
| wgrant | lifeless: That's traditionally SPPH WHERE datepublished IS NULL | 10:40 |
| wgrant | lifeless: But in your proposal that would be maintained separately. | 10:40 |
| lifeless | wgrant: that queue could be explicit as job entries though, yes? | 10:40 |
| wgrant | So we'd a set of events to publish the files. | 10:40 |
| wgrant | Yes. | 10:40 |
| lifeless | I think this is the best approach so far. | 10:40 |
| wgrant | Yeah | 10:40 |
| wgrant | It means rewriting a bit more. | 10:40 |
| wgrant | It's by far the cleanest. | 10:40 |
| wgrant | It's a significant amount of extra work. | 10:41 |
| wgrant | I discounted it as being too much work, so I don't really have a good estimate of how much work it would be. | 10:42 |
| wgrant | But it basically means rewriting the entire backend. | 10:42 |
| wgrant | Rather than just extending it in a couple of places. | 10:42 |
| lifeless | we can let james_w and jml decide. | 10:43 |
| lifeless | I suspect that 'more work' here giving a more debuggable and understandable system is well worth it. | 10:43 |
| lifeless | probably a smaller system too when I think about it. | 10:44 |
| lifeless | bigger change from what we have today - sure. | 10:44 |
| wgrant | It's also throwing away 7-year-old tried and battle-tested code, and forcing people who don't know Soyuz to rewrite Soyuz :) | 10:44 |
| lifeless | wgrant: can you expand a little on the concurrency issue with parse-ppa-apache-access-logs ? | 10:44 |
| wgrant | But they do have packaging experience, so I guess all is not lost :) | 10:44 |
| lifeless | wgrant: the latter is a good thing | 10:44 |
| lifeless | wgrant: fresh eyes, no stockholm syndrome. | 10:45 |
| wgrant | lifeless: Redesigning Soyuz perhaps. | 10:45 |
| lifeless | wgrant: precisely. | 10:45 |
| wgrant | Rewriting Soyuz with the same data model and all the boobytraps it has? No. | 10:45 |
| lifeless | now, -logs thingy. | 10:45 |
| wgrant | lifeless: Well, we currently parse n lines at a time. | 10:45 |
| wgrant | lifeless: And then update the counts all at once. | 10:46 |
| wgrant | lifeless: If n is too large, we'll get lots of rollbacks. | 10:46 |
| wgrant | As there'll be conflicting count updates. | 10:46 |
| lifeless | so by problems you mean 'lots of waste' vs 'bad data' | 10:46 |
| wgrant | There's also the ParsedApacheLog problem, but I may be too paranoid there. | 10:46 |
| wgrant | We currently identify a log file by its first line. | 10:46 |
| lifeless | antything else ? | 10:46 |
| wgrant | If two logs happen to have the same first line, they'll be confused. | 10:47 |
| wgrant | THat's all I know about. | 10:47 |
| lifeless | wgrant: whats the cycle for log parsing | 10:49 |
| lifeless | cron? /15 ? | 10:49 |
| wgrant | lifeless: cron, disabled | 10:49 |
| wgrant | But something around there. | 10:49 |
| * wgrant checks. | 10:50 | |
| lifeless | ok | 10:50 |
| lifeless | wgrant: and how long does it take when it runs? 2-3m ? | 10:50 |
| wgrant | It's */30 | 10:50 |
| wgrant | I don't know how long it takes nowadays. | 10:50 |
| wgrant | It was set up before I worked here, and I haven't had cause to look at it since. | 10:50 |
| wgrant | So I have no clue how long it ever took on prod. | 10:51 |
| wgrant | Ah, we still have logs. | 10:51 |
| * wgrant looks | 10:51 | |
| wgrant | lifeless: Seems to take 5-10 minutes at load of about 6. | 10:52 |
| jml | man, it would be great if pagetests handled unexpected form submission errors by showing the unexpected form submission errors. | 10:54 |
| wgrant | jml: The appserver just says "Unexpected form data". It doesn't give any extra data. | 10:55 |
| jml | wgrant: I mean in cases where validate() shows errors but the test wasn't expected it to | 10:55 |
| wgrant | Oh | 10:56 |
| wgrant | Handy. | 10:56 |
| === matsubara is now known as matsubara-lunch | ||
| lifeless | jml: ...pagetests... | 10:58 |
| lifeless | jml: is all I saw. | 10:58 |
| jml | well, it'd also be great if Launchpad had an app server that wasn't also a web server. | 10:59 |
| jml | i.e. if the web UI was an api client | 10:59 |
| lifeless | jml: funny you should mention that. | 10:59 |
| nigelb | wallyworld_: \o/ suprise surprise! | 11:55 |
| === garyposter is now known as gary_poster | ||
| === matsubara-lunch is now known as matsubara | ||
| jml | some names appear twice (need to do proper fuzzing), but here's a lines-of-code high score table: http://paste.ubuntu.com/1037100/ | 12:27 |
| wgrant | jml: Curses. | 12:30 |
| jml | wgrant: that you aren't on top, or that the numbers add up to 10k+ LoC added since the policy? | 12:30 |
| jml | (incidentally lp:bzr-damage; 'bzr high-scores -r 14780..') | 12:31 |
| wgrant | That I'm not on top, indeed. | 12:32 |
| wgrant | I wonder what Aaron deleted. | 12:33 |
| wgrant | Maybe that was ec2. | 12:33 |
| jml | I reckon so. | 12:33 |
| jml | wgrant: 'bzr loc' (takes log args) will get you that info | 12:33 |
| wgrant | 30 files changed, 679 insertions(+), 6078 deletions(-) | 12:33 |
| wgrant | Yup | 12:33 |
| wgrant | jml: Nice, thanks. | 12:33 |
| * jml is just adding a bunch of todos to the code base before taking a break. | 12:34 | |
| jml | wgrant: my pleasure. | 12:35 |
| jml | wgrant: although it's not nice, it's hideous. | 12:35 |
| cjwatson | jml: Oh, fantastic, I'd been meaning to get round to doing that. | 12:36 |
| jml | cjwatson: my pleasure. I got stuck in a mental groove. | 12:37 |
| jml | cjwatson: I might merge loc-contributors into bzr-damage at some point, if you don't mind | 12:38 |
| * jml might also merge bzr-damage into bzr-stats | 12:38 | |
| jml | the really annoying thing is the way pqm sets itself as author & committer. | 12:38 |
| wgrant | Yeah, it would be pretty handy if it didn't do that. | 12:39 |
| jml | I know lifeless says that it's the right thing for it to do, but accumulating authors from the merged revisions is expensive and hard to slot into bzr's other mechanisms | 12:39 |
| cjwatson | I found that too. | 12:39 |
| cjwatson | And it makes logs tedious to read. | 12:39 |
| jml | although to be fair, the bzr developers would probably admit that bzrlib.log is in need of love | 12:40 |
| StevenK | jml: I personally think that PQM needs to die a horrid, painful and *SLOW* death, but lifeless disagrees. :-( | 12:40 |
| wgrant | jml: Does lifeless say that? | 12:40 |
| wgrant | Surely I'm the author; I told it what to do. | 12:40 |
| jml | I'm thinking of spinning out the pqm hackery I've done here into a separate plugin that tweaks 'bzr log' behaviour by default. | 12:40 |
| jml | wgrant: IIRC. It was a conversation long, long ago. Perhaps on IRC, perhaps not. | 12:41 |
| jml | or I guess I could patch bzr proper | 12:42 |
| jml | what I want to know is what wallyworld_ has been up to | 12:42 |
| wgrant | jml: Oh? | 12:42 |
| wgrant | What has wallyworld_ been up to? | 12:43 |
| StevenK | jml: Why are you stalking wallyworld_? | 12:43 |
| jml | StevenK: because my script says he has added 12k+ lines of code, which makes him an outlier | 12:44 |
| wgrant | Ah. | 12:44 |
| wgrant | He's been writing disclosure stuff. | 12:44 |
| wgrant | Lots of frontend and backend stuff. | 12:44 |
| jml | wgrant: and that's under a LoC exemption? | 12:44 |
| * jml finds that surprising. | 12:44 | |
| wgrant | I believe so. | 12:44 |
| StevenK | disclosure is, yes | 12:44 |
| wgrant | And there's a lot of code that will be deleted once this is done. | 12:45 |
| StevenK | jml: A lot of wallyworld_'s LoC was from writing a whole new services - ISharing | 12:45 |
| wgrant | StevenK: That's hardly relevant. | 12:45 |
| wgrant | It's still LoC. | 12:45 |
| wgrant | All LoC is equal. | 12:45 |
| StevenK | He has also been pilling on bunch of JS | 12:45 |
| wgrant | That's the idea of the policy. | 12:45 |
| jml | Hmm. I'm also not sure how to count the commits from PQM | 12:48 |
| jml | I'm fairly sure they are merges from db-stable | 12:48 |
| wgrant | That was a problem with community-contributions.py. | 12:49 |
| wgrant | I'm pretty sure i fixed it years ago. | 12:49 |
| wgrant | Might be able to steal stuff from that. | 12:50 |
| wgrant | Oh right, no, it's hideous. | 12:50 |
| wgrant | Don't go near that. | 12:50 |
| wgrant | It does work, though. | 12:50 |
| jml | yeah. | 12:52 |
| jml | I'm thinking of merging some of that into bzr-(damage|stats) too. | 12:53 |
| jml | I wish bzr were more popular | 12:53 |
| jml | then I'd feel happier about doing that sort of thing | 12:53 |
| jml | rather than slightly constrained by a weird ocd variant. | 12:53 |
| wgrant | Heh | 12:54 |
| wallyworld_ | jml: what's wrong with adding code? it's sort of impossible to write a new feature without adding code to implement it don't you think? | 12:57 |
| jml | wallyworld_: Certainly it requires new lines. However, those new lines can also be accompanied by removed lines. | 12:58 |
| jml | wallyworld_: have you followed Drizzle at all? | 12:58 |
| wallyworld_ | jml: why does it follow that one must remove lines just because a new feature has been added? | 12:59 |
| wallyworld_ | i haven't followed drizzle | 12:59 |
| === Ursinha` is now known as Ursinha | ||
| === Ursinha is now known as Guest63012 | ||
| jml | wallyworld_: it doesn't necessarily follow, however it's possible and perhaps desirable to insist that you do so. | 13:00 |
| wallyworld_ | hmmm. | 13:00 |
| wallyworld_ | i don't see a correlation, but that's just me | 13:01 |
| wgrant | wallyworld_: The idea of the policy is that new code can't be added. | 13:01 |
| jml | wallyworld_: Launchpad has a lines-of-code freeze policy. It's possible to write a new feature but also "pay" for it by removing other pointless code as you're adding the new feature. | 13:01 |
| wgrant | Therefore from adding code it follows that you must remove a corresponding amount. | 13:02 |
| jml | wallyworld_: However, the team doing disclosure has decided not to do it. | 13:02 |
| wallyworld_ | yes, for good reason :-) | 13:02 |
| jml | wallyworld_: what's that reason? | 13:02 |
| wallyworld_ | it's a bit silly to artifically find stuff to delete just because a new feature is being done' | 13:02 |
| wgrant | Hm? | 13:02 |
| wgrant | That's not silly. | 13:02 |
| wallyworld_ | sort of adds unnecessary scope to the feature writing | 13:02 |
| wgrant | That's the whole point of the policy. | 13:02 |
| jml | oh right, you disagree with the lines of code policy | 13:02 |
| wallyworld_ | in some circumstances yes | 13:03 |
| wallyworld_ | like bespoke feature development | 13:03 |
| jml | hah! | 13:03 |
| wallyworld_ | which we have an exemtiion for | 13:03 |
| wallyworld_ | for good reason imho :-) | 13:03 |
| wgrant | IMO the only excuse we have is that we started 6 months before the policy. | 13:03 |
| wgrant | New features will be started with the policy in mind. | 13:04 |
| wallyworld_ | i've never ever seen such a loc policy applied to bespoke feature devellopment | 13:04 |
| wgrant | Ours was not. | 13:04 |
| wgrant | wallyworld_: Really? | 13:04 |
| jml | wallyworld_: your good reason being that it adds unnecessary scope? | 13:04 |
| wallyworld_ | yes, really | 13:04 |
| wgrant | wallyworld_: workitems was done under LoC freeze. | 13:04 |
| wgrant | wallyworld_: cjwatson's work is under LoC freeze. | 13:04 |
| wgrant | celery was done under LoC freeze. | 13:04 |
| wallyworld_ | jml: yes, and completity and muddles the cleat thought on how best to architect the feature | 13:04 |
| jml | and I believe all the work on drizzle (or one of the mysql forks) over the last few years was done under a LoC freeze. | 13:05 |
| wgrant | Launchpad is far too big considering what it does. | 13:05 |
| wallyworld_ | it may be possible, doesn't make it right thing to do | 13:05 |
| wgrant | Without the LoC freeze there's nothing convincing people to fix that. | 13:05 |
| wgrant | The last 7 years have shown that very well. | 13:05 |
| wallyworld_ | that's what maintenance should be for | 13:06 |
| jml | and it is, but it's hard with a leaky bucket. | 13:06 |
| wallyworld_ | imagine starting a new project from scratch. bit hard for a loc freeze there. a new bespoke feature sort of falls into that category. it shouldn;t be tied to sins of the past | 13:07 |
| cjwatson | It clearly wouldn't work for a newer project, but for a mature project that's well-known to contain lots of cruft I think it's an interesting enough policy that I'm happy to support it by finding stuff to delete. | 13:07 |
| cjwatson | I do waver between thinking it's insanity and thinking it's genius | 13:08 |
| wallyworld_ | i agree somewhat if the new work builds on or it related to previous cruft | 13:08 |
| czajkowski | cjwatson: fine line is it :) | 13:08 |
| cjwatson | Yeah | 13:08 |
| cjwatson | But there is something to be said for requiring refactoring along the way; rather like how review often doesn't happen unless it's a requirement, because it's not the obvious shortest path to churning out lots of code | 13:08 |
| wallyworld_ | i'm all for refactoring, but not as a required, mandatory cost of adding a new unrelated feature | 13:09 |
| jml | wallyworld_: you're saying disclosure *isn't* related to previous cruft? | 13:09 |
| cjwatson | Sometimes if it isn't mandatory it won't happen. | 13:09 |
| wallyworld_ | jml: there's arguments both ways | 13:10 |
| cjwatson | I mean, maybe maintenance should be doing refactoring, but there's those 300-odd critical bugs whose line has been trending the wrong way ... | 13:10 |
| wallyworld_ | i do think it is a primarily a maintenance thing | 13:11 |
| jml | wallyworld_: if it's not related, you should be implementing it as a separate service from Launchpad | 13:11 |
| wallyworld_ | and a best effort thing whre it makes sense for feature work | 13:11 |
| cjwatson | Admittedly I'm doing much smaller feature work than you are, but I also found that the policy forced me to think about economy of implementation, generally for the better. | 13:11 |
| wallyworld_ | jml: the new sharing service stuff is essentially a separate bit of infrastructure, a new paradigm | 13:12 |
| cjwatson | People doing feature work can very likely churn out lines of code much faster than maintenance programmers can refactor them, so saying it's primarily maintenance is (I think) dooming the project to unbounded growth | 13:12 |
| jml | cjwatson: +1 | 13:12 |
| wallyworld_ | cjwatson: i would argue that one should be thinking about that sort of stuff regardless :-) | 13:13 |
| cjwatson | And since one of the initial axioms here appears to be that Launchpad is too large ... | 13:13 |
| wallyworld_ | i wish we were having this discussion over a few beers down at the pub :-) | 13:14 |
| cjwatson | Yeah :) | 13:14 |
| * wallyworld_ would then challenge jml to another arm wrestle | 13:14 | |
| cjwatson | Oh, speaking of branches that add stuff to be traded off against later deletions, I could use a review of https://code.launchpad.net/~cjwatson/launchpad/export-change-override/+merge/109549 | 13:14 |
| czajkowski | gmb: ^^ | 13:14 |
| jml | wallyworld_: you're more than welcome to next time we meet. | 13:15 |
| * wallyworld_ is scared now | 13:15 | |
| jml | http://wiki.drizzle.org/FAQ#Can_I_get_involved.3F | 13:17 |
| * jml → lunch | 13:17 | |
| gmb | cjwatson, czajkowski: Noted, will take a look, ta. | 13:39 |
| sinzui | gmb, do you have time to review https://code.launchpad.net/~sinzui/launchpad/uncommercial-projects/+merge/109404 | 14:02 |
| gmb | sinzui, I will do shortly. | 14:02 |
| sinzui | thank you | 14:02 |
| deryck | adeuring, abentley, rick_h -- coming for standup sorry | 14:03 |
| deryck | adeuring, https://plus.google.com/hangouts/_/4f2b2de401df7d5f9167b0f44c74671388ee17b4?hl=en | 14:05 |
| === al-maisan is now known as almaisan-away | ||
| === Guest63012 is now known as Ursinha | ||
| === Ursinha is now known as Guest90889 | ||
| === Guest90889 is now known as Ursula | ||
| gmb | sinzui, So, benji looked at the code yesterday and has given it r=, but he's asked me to double-check some of the logic... I'll take a look presently and get back to you. | 15:04 |
| benji | gmb: here's an odd MP for you: https://code.launchpad.net/~benji/launchpad/bug-1011793/+merge/109871 | 15:36 |
| gmb | Ooh, lovely. I loves me some oddness. | 15:37 |
| gmb | Hah. | 15:37 |
| gmb | Nice. | 15:37 |
| gmb | benji, r=me | 15:37 |
| benji | thanks | 15:37 |
| jml | benji: it might be a good idea to add a README to that directory so someone doesn't remove it thinking "what the heck is an empty directory in VCS for?" | 16:05 |
| benji | jml: good call, I'll do so | 16:07 |
| gmb | sinzui, r=me | 16:19 |
| sinzui | thank you gmb | 16:20 |
| === salgado is now known as salgado-lunch | ||
| === matsubara is now known as matsubara-afk | ||
| === salgado-lunch is now known as salgado | ||
| * cjwatson upgrades mawson | 17:39 | |
| lifeless | gary_poster: hey, it might be nice if your buildbot log wiki page included the duration. | 18:08 |
| lifeless | gary_poster: just for my prurient interest :) | 18:08 |
| gary_poster | lifeless, heh, ok will do | 18:08 |
| cjwatson | Have to go now, but I've upgraded dogfood and will QA my patch on it later. | 18:14 |
| lifeless | wgrant: can you update the diagram? take apache out. | 19:33 |
| === slank` is now known as slank | ||
| === slank is now known as Guest2077 | ||
| wgrant | lifeless: Not without justification :) | 22:13 |
| lifeless | wgrant: we don't need it; elmo surprised me and said 'lets use squid directly for http', then we spoke about SSL and he decided that squid would be fine for that too, if I was telling the truth about how squid does SSL. | 22:14 |
| wgrant | lifeless: Hopefully we can also do the header mangling with need in Squid, then :) | 22:28 |
| wgrant | But elmo was the main reason I thought we'd need Apache, so sounds good. | 22:29 |
| === salgado is now known as salgado-afk | ||
| lifeless | wgrant: we can at a pinch ignore the outbound side cache headers, I suspect ppa.l.n doesn't do stuff there anyhow. | 22:37 |
| lifeless | wgrant: there is a header replacement system though | 22:38 |
| lifeless | http://www.squid-cache.org/Doc/config/reply_header_replace/ | 22:38 |
| lifeless | may need to tweak that to permit acl based rules I guess | 22:39 |
| wgrant | lifeless: ppa.launchpad.net doesn't need to do it at present. | 22:43 |
| wgrant | lifeless: Since the static files don't have Expires: $FOREVER | 22:43 |
| wgrant | Librarian responses wil | 22:44 |
| lifeless | point is, we can set a global value trivially | 22:44 |
| lifeless | we can't do sophisticated setting today. | 22:44 |
| wgrant | Right. | 22:44 |
| lifeless | what ppa.l.n does is roughly equiv to a global value | 22:45 |
| wgrant | lifeless: That's done, btw. | 23:04 |
| cjwatson | Bug 914779 - broken, but is that qa-ok based on my comments? I've checked that things like Archive.newComponentUploader and Archive.newPackageUploader still works, so it's a matter of attempted new functionality being broken rather than a regression. | 23:28 |
| _mup_ | Bug #914779: Pocket maintainers cannot always upload to their pocket <qa-needstesting> <Launchpad itself:Fix Committed by cjwatson> < https://launchpad.net/bugs/914779 > | 23:28 |
| cjwatson | *still work | 23:28 |
| StevenK | cjwatson: If it does not impact existing functionality and is safe to deploy, then you can mark as qa-ok. | 23:30 |
| cjwatson | Right, thanks. I'll fix it properly tomorrow. | 23:31 |
| cjwatson | Modulo being in a sprint for something else. | 23:31 |
| lifeless | wgrant: elmo raises a concern about FDT impact | 23:48 |
| lifeless | wgrant: I'll talk with him tomorrow; I think its doable offhand, because a) SC can't complete during FDT *anyway*, and most users have the GUI update-manager which is doing background updates - they won't notice | 23:49 |
| wgrant | lifeless: Yeah. | 23:55 |
| wgrant | I think it's manageable for now. | 23:55 |
| wgrant | And we can eliminate it entirely later. | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!