501 Method Not Implemented

[00:38] fun - OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol [00:38] Unable to establish SSL connection. [00:39] wallyworld__: so just an fyi along the lines of what I was thinking. https://pastebin.canonical.com/75528/ is where I'd head to try to make sure the privacy.js is decoupled from the information_type.js aside from listening to the event. [00:40] erm wtf [00:40] telnet> open 10.0.3.24 443 [00:40] Trying 10.0.3.24... [00:40] Connected to 10.0.3.24. [00:40] Escape character is '^]'. [00:40] HELO [00:40] [00:40] [00:40] 501 Method Not Implemented [00:40] :) [00:41] rick_h_: looks ok at first glance. the get_banner_text function can probably be taken off the namespace now with these changes [00:41] right, thats better. [00:41] wallyworld__: right, not complete [00:42] wallyworld__: but I wanted to kind of clear up the idea/where I'm trying to head to make sense of it more [00:42] whoever had that apache not working to lp.dev before, if you're using lxc etc, make sure your apache config is listening on *:443, not 192.160.0.88:443 [00:43] lifeless: I added a feature to Makefile to do that, which I added to the LP LXC docs [00:43] rick_h_: looks ok so far but i probably need to get into the code a little more. i'd run your changes by jc since he did some banner work a few months ago [00:43] wgrant: I was giving the lp-setup inline docs a spin [00:44] wgrant: they are incomplete [00:44] wallyworld__: yea, honestly I'm afk for a week so I'd not worry about it too much. Just hoping to make me seem les insane [00:44] (because it goes for test-suite capability) [00:44] rick_h_: np. it's all good [00:44] * rick_h_ swears he's not lost it yet [00:51] lifeless: Right [01:14] how do I set up the combo loader stuff ? [01:15] lifeless: Should just need to set 'js.combo_loader.enabled default 0 true' [01:15] May need to make combobuild, but the usual targets should do that [01:15] lifeless: which part? the actual hosting bit? or just enabling? [01:15] I have a fresh lxc [01:15] I've run lp-setup update [01:15] and sudo make install [01:15] then it should be setup to combo build ootb. I thought the combo loading FF was on by default. [01:15] I'm getting reference errors [01:16] [13:14:08.562] ReferenceError: YUI is not defined @ https://launchpad.dev/product-name-100011/+milestone/unique-from-factory-py-line878-100017/+index:53 [01:16] [13:14:08.562] ReferenceError: LPJS is not defined @ https://launchpad.dev/product-name-100011/+milestone/unique-from-factory-py-line878-100017/+index:110 [01:16] Check your browser's HTTP request log [01:16] lifeless: make combobuild ? [01:16] [13:14:08.330] GET https://launchpad.dev/+combo/?yui/yui/yui-min.js&lp/meta.js&yui/loader/loader-min.js [HTTP/1.1 200 OK 226ms] [01:16] Aha [01:16] Go to that URL [01:16] It probably says "missing" everywhere [01:16] /* yui/yui/yui-min.js */ [01:16] and if it's missing then check build/js/... [01:16] /* [missing] */ [01:16] which is what combobuild does [01:16] /* lp/meta.js */ [01:17] Yeah, make combobuild would be my suggestion [01:17] make run doesn't do it ? [01:17] Perhaps lp-setup uses a custom target that doesn't include it [01:17] It should... [01:17] make combobuild [01:17] utilities/js-deps -n LP_MODULES -s build/js/lp -x '-min.js' -o \ [01:17] build/js/lp/meta.js >/dev/null [01:17] utilities/check-js-deps [01:17] and jsbuild_watch which will should get lined up with combobuild [01:17] ctrl-refresh, same stuff in that url [01:17] Hm [01:17] make inplace [01:17] there are a lot of LP modules present [01:17] lifeless: anything in build/js? [01:17] its not an empty combo response [01:17] Oh [01:18] var LP_MODULES = (function(){ [01:18] Do you have a YUI version flag set? [01:18] f'r instance [01:18] no [01:18] neither does qastaging [01:18] Right, it's not necessary [01:19] LP_MODULES is from the build/js/lp/meta.js so that's a good sign [01:19] lifeless: Does the /srv/launchpad.net/convoy symlink point to a reasonable location? [01:19] lifeless: so is there anything in build/js/yui ? [01:19] maybe some failure to get that dep right? [01:20] lrwxrwxrwx 1 robertc robertc 59 2012-09-28 01:18 convoy -> /home/robertc/source/launchpad/lp-branches/working/build/js [01:20] ls build/js/yui [01:20] yui-3.3.0 yui-3.5.1 [01:20] So that's all fine. Must be a buildout issue [01:20] Huh [01:20] yui should be a symlink to yui-3.5.1, shouldn't it? [01:20] there are two instances of 'missing' in the https://launchpad.dev/+combo/?yui/yui/yui-min.js&lp/meta.js&yui/loader/loader-min.js response AFAICT [01:20] no, should have build/js/yui symlink to 3.5.1 [01:21] lifeless: right, yui-min.js and load-min.js are coming from the yui libary [01:21] https://launchpad.dev/+combo/?yui-3.5.1/yui/yui-min.js&lp/meta.js&yui-3.5.1/loader/loader-min.js will work since you have that dir [01:21] Is build/js/yui a symlink? [01:21] but you should have the yui symlink to yui-3.5.1 as the 'default' yui version and that's missing somehow [01:22] wgrant: right [01:22] build/js$ ls -ld yui [01:22] drwxr-xr-x 2 robertc robertc 4096 2012-09-28 01:18 yui [01:22] its a directory not a symlink [01:22] lifeless: so yea, that's the issue [01:22] rm it ? [01:22] no, you need it, it needs to be the symlink, loading up my lxc to look at what makes that symlink sec [01:22] On my lpsetup-created instance it's a symlink as expected [01:23] well, this is bind mounted [01:23] as you'd expect [01:23] I've had this working tree for yonks [01:23] Ah, so it's an existing checkout? [01:23] Right, so I'd make clean_buildout build [01:23] of course [01:23] right, clean it up and rerun then [01:24] right, combo-rootdir will do the symlink if it doesn't exist. Since you have a directory it's failing to generate it [01:25] not sure how you got the directory there, but that's causing it to fail. a clean_buildout and make should work [01:25] ok, thats a lot bigger [01:25] still funky [01:26] 1000 unassigned bugs is 11 seconds to render [01:26] thats very interesting [01:27] Bugs and people have a few enums [01:30] I get Y.lp is undefined still [01:30] Any [missing]s? [01:30] yes [01:30] between meta.js and yui/loader/loader-min.js */ [01:31] So meta.js is missing? [01:31] /* lp/meta.js */ [01:31] /* [missing] */ [01:32] needed a make combobuild in that recipe you gave me === matsubara is now known as matsubara-afk [01:33] 5.56 seconds now [01:33] so the 10K was noise of some sort [01:33] e.g. sitting on battery ;) [02:10] 40% time reduction neuterin the tal in lib/lp/registry/templates/milestone-macros.pt [02:11] ah, late eval queries [02:11] storm cache strikes again I bet. [02:11] * lifeless looks for the hammer [02:12] storm_cache_size [02:12] configs/development/launchpad-lazr.conf [02:12] yeah [02:12] do you remember the prod size? [02:12] [and why can't we just toss the damn thing..] [02:12] 10000 I think [02:13] We need *a* size [02:13] well [02:13] why? [02:13] At least for scripts [02:13] we discard the cache after every request [02:14] Sure, for the webapp the limit can be quite ridiculous [02:14] set a ulimit for scripts, so ones that try to do too much in one pass can fail hard [02:14] For scripts it might want to be more sensible. [02:14] or just have a non-discarding cache with a low fixed limit for scripts [02:14] Hm [02:14] Why do we still have two storm_cache_size keys... [02:15] I thought I removed all the duplicates [02:15] 2.5 seconds with minimal td entries [02:15] What'd you change? [02:16] neutered all the bug data access [02:16] Ah [02:16] getting a baseline for doing that many td rows [02:16] 2.7 seconds with the first cell filled in [02:16] same amount of HTML output [02:17] running several times and taking min of course [02:19] [02:19] [02:19] [02:19] [02:19] ^ 0.2 seconds over 1000 rows [02:22] vs [02:22] [02:22] [02:22] [02:23] So, while I clean up this storm_cache_size stuff I think I might remove the development override [02:23] It doesn't make much sense [02:24] +1 [02:24] We keep having to work around it in tests [02:25] Heh [02:26] In fact, the main tests that override the limit are for ProjectMilestone:+index... [02:29] wgrant: where is structure defined [02:29] lifeless: In templates? [02:29] Or in our Python? [02:30] It's a TAL keyword; it's not defined as such anywhere [02:30] the implementation [02:32] emitSubstitution in talgenerator.py - closing in on it [02:32] Right, it's in zope.tal [02:33] Or chameleon if the page uses that [02:33] But I believe that one's still zope.tal [02:34] def do_insertStructure_tal(self, (expr, repldict, block)): [02:52] whoa [02:52] 18K permission checks [02:52] I /really/ want to rip that out entirely [02:53] We would need a pretty significant rewrite for that to work [02:53] Plus the checks should be mostly cached, so very very fast [02:54] 5.5K calls are to block implicit flushes, block implicit flushes makes 18K calls to checkPermission [02:55] "makes" [02:55] It's a decorator [02:55] I know [02:55] Ah :) [02:56] there are getattr's [02:56] that are blocking flushes [02:56] and checking permissions [02:56] 5.5% of runtime in that stack [02:56] so - 'very very fast' - not so much [02:57] ahha [02:57] wgrant: low hanging fruit: [02:57] _get_sqlobject_store [02:57] wgrant: spot what it does [02:58] The import could be a problem if we were multithreading, but we're not really... [02:58] also block_implicit_flushes is bad too [02:58] wgrant: its a lock [02:58] wgrant: synchronisation primitives are not that cheap [02:58] Sure [02:59] wgrant: also, prod runs two threads - xmlrpc + http [02:59] so we are [02:59] But does the profile show that's an issue? [02:59] importing even existing modules in a tight loop is surprisingly slo [02:59] w [02:59] Right, and the xmlrpc cohabitation is the root of most of our annoying undiagnosable issues [02:59] mwhudson: Namespacing causes problems, news at 11? [02:59] Not namespacing... [03:02] wgrant: http://paste.ubuntu.com/1231593/ [03:02] Indeed [03:03] Although I'd prefer to look at untangling the imports, that should work [03:04] wgrant: its about 300ms over the request. [03:04] wgrant: from a quick timeit + back of napkin [03:05] Hm [03:06] I've seen _get_sqlobject_store show up before in profiles, but hadn't actually looked at it as there were other dominating factors to fix first [03:06] But I haven't profiled in several months [03:07] Anyway, storm_cache_size is now 10000 everywhere in devel [03:08] I meant to do that as followup to my DB config rework branches last year [03:08] Or whenever it ws [03:08] But never got around to it, apparently [03:15] how often is process-upload running these days? [03:20] ok so its hard to tell [03:20] but it looks like it saved 100ms [03:20] wgrant: ^ if you want to do it at some point [03:20] I've got to context switch here [03:21] hard to tell because of the massive variance [03:29] bigjools: */5 for sources [03:29] lifeless: Yeah, and it really really depends on the page whether it's a big issue [03:29] I might try untangling that stuff [03:30] it would be great to make imports barf [03:30] install an import hook [03:30] ta [03:30] hmmm, dunno if cached imports would trigger [03:31] lifeless: We have a lot of inline imports, so we can't do it generally [03:31] wgrant: we could set a cap [03:31] wgrant: 500 imports in a request, then boom. [03:31] Yeah [03:32] that would be about 5ms [03:32] more or less [03:32] I was initially thinking we could do a per-import cap [03:32] But as you say, I'm not sure it'll actually trigger on repetition [03:32] Maybe [03:32] I'm not sure it will trigger at all [03:32] we could hack the bytecode [03:32] but folk might consider that objectionable [03:32] Heh [03:32] Or we could just ban inline imports in lp.services.webapp... [03:33] __import__ is called for cached imports [03:33] says science [03:33] mwhudson: tried monkey patching it ? [03:33] mwhudson: and we were actually speculating about pep whatsisthing hooks [03:34] oh [03:34] yeah, i just overwrote __builtin__.__import__ [03:34] dunno about the hooks [03:37] anyhow replacing __import__ with a thread-local-counting abomination would be effective. [03:37] mwhudson: want to write one [03:37] ? [03:39] i suppose i could try [03:39] where would the output go? same place as the query count? [03:40] mwhudson: Oh, I was thinking super simple: Raise a Mother* exception :) [03:40] oh, when it crosses 500 or something? [03:41] mwhudson: needs a call to install it, probably one to uninstall it, a per-thread 'request starting, kill me after X imports', and 'request finished, don't kill me anymore' [03:41] mwhudson: ^ is how I would do it. [03:43] http://pypi.python.org/pypi/pyjack/ is kindof related [03:43] mwhudson: might want a fifth call to change the threshold mid-request [03:43] wgrant: if you want to look https://code.launchpad.net/~wallyworld/launchpad/duplicate-bug-warning-xss-1057630/+merge/126849 [03:43] mwhudson: would let us featureflag it [03:44] mwhudson: hmm, could minimise down to 4 calls: - install/uninstall/reset_count/set_threshold(None-or-an-int) [03:48] mwhudson: make the set an attribute access, and you've got the ability to read-back too, for oops integration if we care. [03:49] lifeless: i guess there isn't a bug for this? [03:49] nup [03:52] man, I can't get used to this fast ->dbstable bb :) [03:53] how do you guys set things up so you can access launchpad running in an lxc from outside it? [03:53] is it just a matter of putting the right bits in /etc/hosts outside the container? [03:53] wallyworld__: Might it be worth mustaching this instead? This still injects dup_id directly, which is only safe today because of constraints we place on this particular piece of data [03:54] mwhudson: Right, Makefile takes a variable to make Apache listen on *, and then I drop stuff in /etc/hosts [03:54] make install LISTEN_ADDRESS=* ? [03:55] Should be on https://dev.launchpad.net/Running/RemoteAccess [03:55] But that looks like it [03:55] seems to be [03:58] ProgrammingError: function pg_last_xact_replay_timestamp() does not exist ? [03:58] oh [03:58] You fail at 9.1 [03:58] i probably haven't updated launchpad-dependencies in the container for eons [03:58] Yeah [03:58] The following packages have been kept back: [03:58] ... launchpad-database-dependencies [03:58] hm [03:59] dist-upgrade? [03:59] oh right [03:59] yes, seems happier [03:59] Then you'll probably want to purge 8.4, then drop and recreate the 9.1 cluster to get it on port 5432 [03:59] Then rerun utilities/launchpad-database-setup and all will be good [04:01] ah yes [04:02] lifeless: I think db-stable should die. It's not clear what should happen to db-devel, but it's awfully heavyweight for what we want it for. [04:03] i guess what's actually going to happen here is that i'll get to the point where i could do some launchpad development [04:03] StevenK: how would you assess 'db and code work well together' ? [04:03] and then it'll be time to go home [04:04] mwhudson: Are you coming back to us? [04:04] StevenK: not formally :) [04:05] mwhudson: Oh, so you're going to tease us with a few bug fixes? :-) [04:05] i would still like to kill the branch puller [04:07] Can you kill the branch scanner too? [04:07] Get:68 http://archive.ubuntu.com/ubuntu/ lucid-updates/main libmysqlclient16 5.1.63-0ubuntu0.10.04.1 [1,898kB] [04:07] whut [04:08] the path to that is less clear i think [04:08] mwhudson: stub had a pretty brilliant idea, I thought [04:08] mwhudson: A DB backend for bzr so when you push a branch, it directly hits the DB, no muss, no fuss [04:09] ah yeah [04:09] I thought I was trolling? [04:09] i think i first heard that idea from mark, actually :-) [04:09] i don't know if he was trolling either [04:09] it would be awesome, but also a great deal of work [04:09] bzr is a db [04:09] In theory, it is a great idea. [04:09] yeah, what he said [04:09] so, ITYM *another* DB backend [04:10] Fine, a *postgresql* backend [04:10] create table versionedfile (...) [04:10] what could go wrong [04:10] So then the question becomes "oh god why" [04:13] Configuring postgresql.conf to use port 5433... [04:13] oy you [04:13] Did you purge 8.4 and drop the existing 9.1 cluster? [04:14] yes [04:14] :( [04:14] oh [04:14] maybe i didn't purge all of 8.4 [04:14] yeah, oh [04:15] ok, that's better [04:20] woo [04:20] stub: looks like my format-relative-imports branch didn't come through. :( I got the EC2 success message, but no landing. [04:22] um [04:22] the importfascist still exists? [04:22] Yes. [04:22] It doesn't do very much [04:23] But it still exists [04:23] And someone angered it earlier this week [04:23] jtv: I'll try the landing step again. I too got the success message. [04:23] stub, jtv: We were in testfix for several hours [04:23] Probably got caught in that [04:23] database_root = 'canonical.launchpad.database' [04:24] jtv: Do you have the mp url handy? [04:24] * mwhudson spots some dead code [04:29] oh yay, bootstrapping [04:30] stub: https://code.launchpad.net/~jtv/launchpad/format-relative-imports/+merge/124878 [04:32] heh [04:32] https://code.launchpad.dev/applets -> 522 imports [04:33] or 1713 for the first request after app server startup :) [04:37] wgrant: i could look at mustache i guess. we know the id is an int, so i saw no need to do anything special with it [04:41] lol what [04:41] one of the main offenders is get_current_browser_request doing "from zope.security.management import queryInteraction" inline [04:41] which is probably only to keep lazr.restful from unconditionally depending on zope ? [04:42] wallyworld__: trusting the integrity of over the wire data is risky [04:42] mwhudson: Heh [04:43] mwhudson: lazr.restful shoul always depend on zope [04:43] i guess i need to be more paranoid [04:43] lifeless, wallyworld__: It's not so much the integrity of the wire. It's the fact that changing something on the server will subtly make unnecessarily fragile client code vulnerable [04:43] mwhudson: the folk making it work for django were being optimists [04:43] yes [04:43] wgrant: I didn't talk about integrity of the wire :) [04:43] wgrant: and yes, I agree. [04:43] i think reality has won there now? [04:43] mwhudson: yes [04:44] mwhudson: if it were to be made separate, it would need to be several more separate projects with callbacks etc [04:44] wallyworld__: eg. in a tonne of places today we inject URLs containing product names unescaped, because people thought it should be safe [04:44] wallyworld__: It's a reasonable assumption, except that it means we have to be really really ultra-paranoid about project names [04:44] sure, but a name is not an integer [04:44] Because if a quote gets in one somehow, we're fucked [04:44] wallyworld__: Bugs have nicknames that are used in some situation [04:45] Eg. bug gbcw [04:45] Or did we remove them, I can't remember. [04:45] http://launchpad.net/bugs/gbcw :) [04:45] Anyway [04:45] Client code shouldn't be unnecessarily fragile [04:45] Partly because it's possible it'll change [04:45] But mostly because people will copy it [04:46] And an argument that people *won't* copy it isn't really valid here, since someone clearly did copy this from elsewhere :) [04:47] Launchpad is really good at convincing people to copy code :( [04:54] wgrant: changes pushed [04:55] wallyworld__: That looks much safer and even shorter, thanks. [04:55] _show_comment_on_duplicate_warning still needs the same treatment, though [04:55] np, thanks for the suggestion [04:56] ah, ok, bug id [04:56] will do [04:56] The mustache implementation isn't precisely fast, but it should be more than fine for a dialogue like this [04:56] wallyworld__: Well, you also extracted the title setting [04:56] So you can merge that back in and save a line [04:56] As well as handling bug_id paranoidly [04:56] yeah, i extracted it because it failed too [04:57] Indeed, thanks for finding that one. [04:58] wgrant, lifeless: Can you think of why Deryck needs this index, when we didn't need similar ones for bug_sharing_policy and branch_sharing_policy? [04:58] https://code.launchpad.net/~deryck/launchpad/product-specification-sharing-policy-idx-1057617/+merge/126728 [04:59] stub: No. It's possible it's for a garbo job, but I thought that was already done. [05:00] So I'm not quite sure what's going on there [05:00] It may be for adding a NOT NULL constraint or something like that [05:00] (and also we established that for a product garbo job it's not worth it) [05:00] Right. In which case a partial index might be preferable, but whatever [05:04] ok [05:04] boringly, i can report that most of the inline imports are in zope.tal :( [05:04] mwhudson: really? FAARK [05:04]