| lifeless | desperately seeking reviewers | 00:24 |
|---|---|---|
| wgrant | lifeless: Where? | 00:25 |
| wgrant | I don't see a lifeless review pending. | 00:25 |
| lifeless | https://code.launchpad.net/~lifeless/launchpad/bug-739799/+merge/54287 | 00:25 |
| wgrant | Oh, it didn't actually exist yet. | 00:26 |
| wgrant | I see. | 00:26 |
| wgrant | lifeless: Still 100ms? :/ | 00:26 |
| lifeless | wgrant: see the oops: 9000ms cold, new query is 900ms cold, 100ms hot | 00:28 |
| wgrant | No thumper, and no StevenK yet I guess :( | 00:30 |
| StevenK | Hmm? | 00:30 |
| === wgrant changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | firefighting: - | On call reviewer: wgrant | https://code.launchpad.net/launchpad-project/+activereviews | ||
| wgrant | StevenK: https://code.launchpad.net/~lifeless/launchpad/bug-739799/+merge/54287 | 00:31 |
| lifeless | next thing is to permit bulk_load chainging | 00:31 |
| lifeless | and we'll have a poor man persistence layer | 00:31 |
| wgrant | Indeed. | 00:31 |
| wgrant | I also need to look at a helper for collections. | 00:32 |
| StevenK | wgrant: Done. | 00:33 |
| wgrant | StevenK: Thanks. | 00:34 |
| wgrant | StevenK, lifeless: https://code.launchpad.net/~cjwatson/launchpad/tar-xz/+merge/54215 | 00:34 |
| lifeless | wgrant / sinzui can you confirm jc is still on Cve:+index ? | 00:37 |
| wgrant | lifeless: He mentioned it on the call this morning. | 00:37 |
| lifeless | kk | 00:37 |
| wgrant | So I think so. | 00:37 |
| lifeless | sob | 00:38 |
| lifeless | I don't want to touch 27 / 26 ProductSet:CollectionResource:#projects | 00:38 |
| wgrant | It's not that bad. | 00:38 |
| wgrant | Just needs a few things preloaded. | 00:38 |
| wgrant | A couple of them are collections, though. | 00:38 |
| lifeless | its a nuisance determining all the traversals being hopped to | 00:38 |
| wgrant | Indeed. | 00:39 |
| wgrant | We may want to fix lazr.restful. | 00:39 |
| wgrant | To provide a hook. | 00:39 |
| lifeless | productseries should be sufficient to make the timeout go away | 00:39 |
| wgrant | That was my impression, but officialbugtag might be bad too. | 00:40 |
| wgrant | StevenK, lifeless: Thanks. | 00:44 |
| lifeless | sinzui: | 00:46 |
| lifeless | Traceback (most recent call last): | 00:46 |
| lifeless | File "bin/sprite-util", line 54, in <module> | 00:46 |
| lifeless | url_prefix_substitutions={'/@@/': '../images/'}) | 00:46 |
| lifeless | File "/home/robertc/launchpad/lp-branches/working/lib/lp/services/spriteutils.py", line 94, in __init__ | 00:46 |
| lifeless | css_template_file, group_name, url_prefix_substitutions) | 00:46 |
| lifeless | File "/home/robertc/launchpad/lp-branches/working/lib/lp/services/spriteutils.py", line 101, in _loadCSSTemplate | 00:46 |
| lifeless | self.css_object = cssutils.parseFile(css_template_file) | 00:46 |
| lifeless | File "/home/robertc/launchpad/lp-sourcedeps/eggs/cssutils-0.9.6-py2.6.egg/cssutils/__init__.py", line 156, in parseFile | 00:46 |
| lifeless | return CSSParser().parseFile(*a, **k) | 00:46 |
| lifeless | File "/home/robertc/launchpad/lp-sourcedeps/eggs/cssutils-0.9.6-py2.6.egg/cssutils/parse.py", line 130, in parseFile | 00:46 |
| lifeless | return self.parseString(open(filename, 'rb').read(), | 00:46 |
| lifeless | IOError: [Errno 2] No such file or directory: '/home/robertc/launchpad/lp-branches/working/lib/canonical/launchpad/icing/style-3-0.css.in' | 00:46 |
| * StevenK glares at run_script. Something looks to be running DELETE FROM FeatureFlag first | 00:51 | |
| lifeless | see jtv's recent landing? | 00:53 |
| lifeless | StevenK: wgrant: any idea about this issue I have ? | 00:53 |
| lifeless | or should I back 12638 out? | 00:54 |
| wgrant | lifeless: Reproduced. | 00:55 |
| lifeless | bah, not that rev. other rev | 00:55 |
| wgrant | lifeless: We have another 3 hours left on buildbot. | 00:55 |
| lifeless | no, actually, that rev | 00:55 |
| wgrant | Let's debug slightly first. | 00:55 |
| lifeless | its trying to build the style-3.0 regardless | 00:56 |
| wgrant | Ah. | 00:57 |
| wgrant | I wonder if bin/sprite-util didn't get rebuilt... | 00:57 |
| lifeless | so the easiest fix is to rename it | 00:57 |
| lifeless | indeed | 00:58 |
| wgrant | Or touch something that buildout depends on. | 00:58 |
| lifeless | removing it | 00:58 |
| lifeless | and it fails to run | 00:58 |
| lifeless | 'make' doesn't know that bin/sprite-util should be rebuilt | 00:58 |
| lifeless | bin/buildout fixed | 00:58 |
| sinzui | style-3-0.css.in should not exit /bin/buildout will fix the utils | 00:58 |
| wgrant | lifeless: Fixed? | 00:59 |
| lifeless | wgrant: made 'make' work | 00:59 |
| sinzui | Looks like the buildout templates were not regenerated during the deploy | 00:59 |
| lifeless | we need to land a dependency rule to rerun buildout | 00:59 |
| lifeless | it may|maynot fail on deploy | 00:59 |
| wgrant | lifeless: It shouldn't fail on deploy. | 00:59 |
| lifeless | wgrant: we don't start with a clean tree | 01:00 |
| lifeless | wgrant: do we explicitly run buildout? | 01:00 |
| wgrant | Then why does it take 30 minutse to run buildout? | 01:00 |
| sinzui | what | 01:00 |
| sinzui | ? | 01:00 |
| lifeless | bbr | 01:01 |
| lifeless | brb | 01:01 |
| wgrant | sinzui: Your change to sprite-util.in wasn't enough to cause buildout to be rerun. | 01:01 |
| wgrant | sinzui: So bin/sprite-util is still old. | 01:02 |
| sinzui | ./bin/buildout will remake the bin dir from the new bin templates | 01:02 |
| wgrant | Right, but until then everyone's tree is broken. | 01:02 |
| wgrant | Maybe I should just upgrade loggerhead. | 01:03 |
| wgrant | Kill two birds with one stone. | 01:03 |
| wgrant | Oh, no. | 01:03 |
| wgrant | versions.cfg, not sourcedeps.conf :( | 01:03 |
| sinzui | Mine wasn't. I think this is case of different setups. I branch and make new trees every tine | 01:03 |
| wgrant | sinzui: I normally do, but sometimes run stuff from devel. | 01:04 |
| wgrant | And as of yesterday I'm trying bzr-colo, so all my one tree is broken. | 01:04 |
| poolie | thanks for trying it | 01:04 |
| poolie | i do use it for lp development fwiw, but not as often as you will be | 01:04 |
| sinzui | I stopped running from devel when we switched to eggs. It became unstrust worthy | 01:04 |
| poolie | what happened? | 01:04 |
| sinzui | I miss simple python and debs | 01:04 |
| wgrant | sinzui: Indeed. | 01:05 |
| wgrant | poolie: Makefile + buildout == confusion | 01:05 |
| wgrant | Compounded by running with a single tree. | 01:05 |
| poolie | sinzui, what's the alternative? | 01:05 |
| poolie | to running from devel, i mean | 01:05 |
| poolie | my frustration here is that i only touch lp stuff every 1-3 weeks and so every time i do, i need to fight with dependencies | 01:06 |
| lifeless | so minimally | 01:08 |
| lifeless | someone needs to mail the dev list | 01:08 |
| lifeless | secondly, we should just fix Makefile to invoke buildout here | 01:08 |
| sinzui | poolie: yes :( I run rocketfuel-setup the moment I start my day, merge and rebuild all my trees. I can review projects, check spam and answer questions, before all that work is complete some days | 01:08 |
| poolie | wgrant, so the breakage is not specifically from bzr-colo? | 01:09 |
| wgrant | poolie: No. | 01:09 |
| wgrant | poolie: colo is working OK, but the fact that it shares trees means that our screwed up build system is more exposed. | 01:09 |
| lifeless | jcsackett: I have a change to lib/lp/bugs/browser/cve.py that may trivially fix the CVE:+index bug, though I'm not sure if it is/isn't related | 01:17 |
| lifeless | jcsackett: actually nvm, I was on (hopeful) crack | 01:19 |
| lifeless | huh | 01:23 |
| lifeless | sinzui: looks to me like there is only one user of ProductSet.search : the API. | 01:23 |
| lifeless | sinzui: if I'm right, could make it siiiiimpler | 01:24 |
| === jtv-afk is now known as jtv | ||
| jtv | morning folks | 01:25 |
| lifeless | wgrant: fyi, offiical bug tags may be an issue, but they are also locked behind a mixing behind a property hidden in a dilemma. | 01:36 |
| lifeless | wgrant: e.g. TooHardBin | 01:36 |
| wgrant | lifeless: Perhaps. | 01:36 |
| lifeless | wgrant: certainly not low hanging fruit | 01:38 |
| jtv | hi StevenK, are you here? | 01:52 |
| sinzui | lifeless: I would expect ProductSetView to use IProductSet.search(). I see it uses IPillarNameSet. I think this is because users do not care care that we divide things into distros, projects, and project groups | 02:09 |
| lifeless | sinzui: I had such expectations too | 02:09 |
| lifeless | sinzui: I found a total of 1 use: bugalsoaffects | 02:09 |
| lifeless | can has review? https://code.launchpad.net/~lifeless/launchpad/bug-727020/+merge/54290 | 02:16 |
| StevenK | jtv: I am now. What are you after? | 02:18 |
| jtv | StevenK: I figured it out for myself now. | 02:18 |
| StevenK | jtv: Nice work. :-) | 02:19 |
| jtv | Well I still haven't solved my problem. :) The difficulty was finding out where Sources gets generated. Turns out the answer depends on the archive purpose. In my case it should be done by a-f. | 02:20 |
| lifeless | StevenK: https://code.launchpad.net/~lifeless/launchpad/bug-727020/+merge/54290, if you would be so kind | 02:31 |
| lifeless | wgrant: how is Archive:+index looking perf wise now, do you think ? | 02:34 |
| StevenK | lifeless: Done. | 02:34 |
| lifeless | thanks | 02:35 |
| wgrant | lifeless: getBuild(Status)?Summar(y|ies)(ForSource(Id)?s(AndArchive)?)? is still being problematic. | 02:35 |
| wgrant | Across +index, +packages, +copy-packages and +delete-packages | 02:35 |
| lifeless | wgrant: want me to look ? | 02:36 |
| lifeless | or I can fix ScopedCollection:CollectionResource:#person-page-resource | 02:37 |
| lifeless | hmm, might do that one | 02:37 |
| wgrant | lifeless: I'm looking. | 02:37 |
| wgrant | Well, was looking before, and will be looking again in a while, I imagine... | 02:37 |
| wgrant | lifeless: It needs to be rewritten to not execute four 300ms queries, basically. | 02:38 |
| lifeless | wgrant: thats only 1.2 seconds | 02:38 |
| wgrant | lifeless: The queries are at best 300ms. They're often much more. | 02:38 |
| StevenK | jtv: Hi! :-) | 02:40 |
| jtv | uh-oh | 02:40 |
| jtv | yes? | 02:40 |
| StevenK | jtv: Is there anything special I need to do to see feature flags in a script? | 02:40 |
| jtv | StevenK: if it's a LaunchpadScript, no. | 02:41 |
| jtv | If it's not a LaunchpadScript, you're still on your own. | 02:41 |
| StevenK | I don't think it is. Can you point me at the scaffolding I need to set up? | 02:41 |
| jtv | Surprisingly, you can find the answer in LaunchpadScript. :) | 02:42 |
| jtv | Have a look at lp.services.scripts.base: LaunchpadScript.run | 02:42 |
| jtv | In a nutshell: | 02:42 |
| jtv | from lp.services.features import install_feature_controller, make_script_feature_controller | 02:42 |
| StevenK | Ah ha, it's a JobCronScript, which bases from LaunchpadCronScript, which is based off LaunchpadScript. | 02:43 |
| jtv | install_script_feature_controller(make_script_feature_controller("identifying script name")) | 02:43 |
| jtv | Well then there you go. | 02:43 |
| jtv | The feature controller is installed only during "run." | 02:43 |
| jtv | After that, it restores whatever controller was previously active (which probably means "none"). | 02:43 |
| jtv | If you call main directly in a test, it uses whatever controller the test had set up. | 02:44 |
| StevenK | I call the cronscript directly using run_script | 02:44 |
| jtv | Then it should just work (apart from ZCML taking #$%@ ages to parse during script startup) | 02:45 |
| StevenK | It insists the feature flag isn't set | 02:45 |
| StevenK | I shall worry about it after lunch | 02:46 |
| jtv | StevenK: my branch landed only recently, so make sure it's included. | 02:47 |
| StevenK | jtv: This is with latest devel merged in | 02:50 |
| StevenK | jtv: Is it because the test set up uses a fixture? | 02:52 |
| jtv | Uses a fixture for what? | 02:52 |
| StevenK | self.useFixture(FeatureFixture({FEATURE_FLAG_ENABLE_MODULE: u'on'})) | 02:52 |
| jtv | Does FeatureFixture actually change your feature-flag settings? Because it'd have to do that to have any influence on your script run. | 02:54 |
| StevenK | jtv: Running the cronscript test by itself with LP_DEBUG_SQL=1, it runs "DELETE FROM FeatureFlag" | 02:54 |
| StevenK | The job gets added, then there is a pause, which is ZCML and such like, and then two statements get executed, the first is the delete, and the second is checking the feature flag which is now unset | 02:55 |
| jtv | No idea where that comes from; does the FeatureFixture also INSERT your test flag (and do you commit before the script runs)? | 02:55 |
| jtv | My impression was that the FeatureFixture is an in-memory trick only, in which case it's not going to do anything for scripts. | 02:56 |
| StevenK | jtv: So this is using the testcase you added :-) | 02:56 |
| jtv | How does that follow? | 02:56 |
| StevenK | If FeatureFixture is in memory only, how do I go about enabling the flag? | 02:57 |
| lifeless | its not in memory only AFAIK | 02:57 |
| lifeless | it was discussed, not done. | 02:57 |
| lifeless | IMBW | 02:57 |
| lifeless | check the code | 02:57 |
| StevenK | lifeless: So how can I tell what is running the DELETE? | 02:58 |
| lifeless | LP_DEBUG_SQL_EXTRA=1 | 02:58 |
| jtv | I'm already running that | 02:58 |
| StevenK | I was right, it is the fixture. | 02:59 |
| lifeless | it should show a backtrace then | 02:59 |
| StevenK | It's cleaning itself up before the script runs | 02:59 |
| lifeless | StevenK: pastebin the code? | 03:00 |
| StevenK | lifeless: It's in an MP: https://code.launchpad.net/~stevenk/launchpad/dsdj-runner/+merge/54159 ; I'm just pushing latest changes | 03:01 |
| StevenK | Unless I cause the fixture to cleanup by running transaction.commit() | 03:02 |
| StevenK | Anyway, lunch | 03:02 |
| StevenK | (Finally) | 03:02 |
| lifeless | grrrrr | 03:09 |
| lifeless | self._fd.close() | 03:09 |
| lifeless | IOError: [Errno 28] No space left on device | 03:09 |
| lifeless | trying to setup a test env | 03:09 |
| lifeless | because sill factory triggers | 03:09 |
| lifeless | File "/home/robertc/launchpad/lp-sourcedeps/eggs/zope.sendmail-3.7.1-py2.6.egg/zope/sendmail/delivery.py", line 136, in createDataManager | 03:09 |
| lifeless | msg.close() | 03:09 |
| lifeless | File "/home/robertc/launchpad/lp-sourcedeps/eggs/zope.sendmail-3.7.1-py2.6.egg/zope/sendmail/maildir.py", line 136, in close | 03:10 |
| lifeless | StevenK: looks like the fixture DELETE should happen at the end of the test, not before | 03:30 |
| === jamesh_ is now known as jamesh | ||
| jtv | wgrant: I'm driving myself up the walls trying to find out why a-f isn't generating any Sources files for me. One thing I notice is that there's no trace of binary packages in the setup that the test publisher has produced for me… is that normal? | 03:50 |
| jtv | I do get a <distroseries>_main_source referring to an existing dsc file… what else is needed? | 03:52 |
| wgrant | jtv: What does the a-f conf look like? | 03:52 |
| * jtv finds pastebin | 03:52 | |
| jtv | wgrant: I hope apt.conf is the one you need… http://paste.ubuntu.com/583629/ | 03:53 |
| wgrant | jtv: That's the one. | 03:53 |
| wgrant | So, that should work. But I wonder if it's not working because you have no DASes. | 03:54 |
| wgrant | I'm not sure anyone has tested that. | 03:54 |
| jtv | So the test publisher doesn't set any up? | 03:54 |
| wgrant | Not if you just makeDistroSeries, no. | 03:54 |
| jtv | Also, the contents.header that that config refers to doesn't exist prior to the a-f run. | 03:54 |
| wgrant | It's not designed to placate buggy a-f stuff. | 03:54 |
| wgrant | Right, that's fine. | 03:54 |
| jtv | Trying it with a DAS in place, just for the hell of it… | 03:55 |
| wgrant | It shouldn't make a difference, but you never know. | 03:56 |
| jtv | I'm just getting more error messages out of a-f. :) | 03:58 |
| jtv | It now also says "could not open file" about the Packages files. | 03:58 |
| wgrant | Could you pastebin the full output? | 03:58 |
| wgrant | Or throw the branch my way? | 03:58 |
| jtv | wgrant: the branch is lp:~jtv/launchpad/bug-55798 ; run ./bin/test lp.soyuz.scripts.tests.test_publish_ftpmaster -t publishes | 04:00 |
| jtv | I've set it up to tar up directory contents in /tmp, though not all of that is committed (because I don't want it in my final branch) | 04:00 |
| StevenK | lifeless: It looks to me that the commit is setting it off | 04:04 |
| jtv | wgrant: another fairly wild guess: if none of this has been tested with distros other than Ubuntu, could something be reacting badly to the test distro not having (or populating) all the pockets that ubuntu has? | 04:09 |
| lifeless | StevenK: the commit will commit all pending stuff | 04:09 |
| lifeless | StevenK: which will include a cleanout of *prior* featureflags | 04:09 |
| lifeless | StevenK: and should include an add of yours | 04:09 |
| lifeless | StevenK: check the FeatureFixture code | 04:10 |
| wgrant | jtv: Sorry, got distracted by uncontrollable anti-Microsoft rage. | 04:10 |
| wgrant | Let's see. | 04:10 |
| jtv | wgrant: never apologize for that. It's Microsoft's fault and don't stop until they're gone. | 04:10 |
| lifeless | argh | 04:12 |
| lifeless | activemembers unions with adminmembers. why | 04:12 |
| StevenK | lifeless: That doesn't explain what I see with LP_DEBUG_SQL_EXTRA. http://pastebin.ubuntu.com/583636/ | 04:14 |
| lifeless | StevenK: thats after the test ran | 04:15 |
| lifeless | File "/home/steven/launchpad/lp-sourcedeps/eggs/testtools-0.9.8-py2.6.egg/testtools/runtest.py", line 154, in _run_cleanups | 04:16 |
| lifeless | StevenK: so its irrelevant to you | 04:16 |
| === Ursinha is now known as Ursinha-afk | ||
| StevenK | Drat, pasted the wrong bit | 04:16 |
| StevenK | lifeless: http://pastebin.ubuntu.com/583637/ | 04:17 |
| StevenK | lifeless: The traceback from the commit is half-way through the test | 04:18 |
| wgrant | jtv: Ah | 04:25 |
| lifeless | StevenK: still in *test* cleanups | 04:27 |
| lifeless | File "/home/steven/launchpad/lp-sourcedeps/eggs/testtools-0.9.8-py2.6.egg/testtools/runtest.py", line 154, in _run_cleanups | 04:27 |
| StevenK | lifeless: So the code for the statement is before the statement, http://pastebin.ubuntu.com/583640/ shows the entire test, and you can plainly see it runs the clean ups after line 6 of the test | 04:30 |
| lifeless | StevenK: this suggests that that commit is failing | 04:33 |
| lifeless | StevenK: raising an exception, which triggers cleanups | 04:33 |
| lifeless | StevenK: i promise you, you've left your entire test according the backtraces you are showing me | 04:33 |
| lifeless | StevenK: if I was debugging this, I would break in with pdb about now | 04:34 |
| LPCIBot | Project db-devel build #477: FAILURE in 5 hr 1 min: https://lpci.wedontsleep.org/job/db-devel/477/ | 04:34 |
| lifeless | argh | 04:35 |
| lifeless | ---------------------------------------------------------------------- | 04:35 |
| lifeless | SELECT 1 FROM (SELECT PersonTransferJob.json_data, PersonTransferJob.id, PersonTransferJob.job, PersonTransferJob.job_type, PersonTransferJob.major_person, PersonTransferJob.minor_person FROM Job, PersonTransferJob WHERE PersonTransferJob.job_type = 1 AND PersonTransferJob.job = Job.id AND Job.status IN (0, 1, 4) AND (PersonTransferJob.minor_person = 251673 OR PersonTransferJob.major_person = 251673) LIMIT 1) AS "_tmp" LIMIT 1 | 04:35 |
| lifeless | ---------------------------------------------------------------------- | 04:35 |
| lifeless | (repeat for the batch size) | 04:35 |
| lifeless | SELECT 1 FROM (SELECT PersonTransferJob.json_data, PersonTransferJob.id, PersonTransferJob.job, PersonTransferJob.job_type, PersonTransferJob.major_person, PersonTransferJob.minor_person FROM Job, PersonTransferJob WHERE PersonTransferJob.job_type = 1 AND PersonTransferJob.job = Job.id AND Job.status IN (0, 1, 4) AND (PersonTransferJob.minor_person = 251672 OR PersonTransferJob.major_person = 251672) LIMIT 1) AS "_tmp" LIMIT 1 | 04:35 |
| wgrant | jtv: Ran 1 tests with 0 failures and 0 errors in 32.236 seconds. | 04:35 |
| jtv | wgrant: yes, but no Sources files. Check /tmp/var_archive.tar.gz. | 04:35 |
| wgrant | jtv: It's empty, but it's there. | 04:37 |
| wgrant | (because I fixed it) | 04:37 |
| jtv | wgrant: you do know how to keep the tension up, don't you? | 04:37 |
| wgrant | Indeed. | 04:37 |
| jtv | How did you fix it, and why is it empty? | 04:37 |
| wgrant | You had your paths wrong | 04:37 |
| wgrant | config.archivepublisher.root on prod is /srv/launchpad.net/ubuntu-archive, not /srv/launchpad.net. | 04:37 |
| wgrant | And what's all this PPA business? | 04:37 |
| wgrant | lp:~wgrant/launchpad/jtv-bug-55798 | 04:40 |
| jtv | What is what PPA business? | 04:40 |
| wgrant | Your test and cron.publish-ftpmaster talk about PPAs. | 04:41 |
| wgrant | cron.publish-ftpmaster does not go near PPAs. | 04:41 |
| wgrant | Oh, right, there was that alternate codepath that could never have worked. | 04:41 |
| jtv | You speak in riddles. | 04:42 |
| wgrant | - ARCHIVEROOT_PARTNER=$PUBLISHER_ROOT/ppa/$DISTRONAME-partner | 04:42 |
| jtv | All my test did was create some ppa directories that appeared to be needed for anything to run. | 04:42 |
| wgrant | You added that. | 04:42 |
| wgrant | Possibly because the original did this: | 04:43 |
| wgrant | - ARCHIVEROOT_PARTNER=/srv/launchpad.net/ppa/ubuntu-partner | 04:43 |
| jtv | How is that different? | 04:43 |
| wgrant | That branch has the minor issue of not making any sense at all. | 04:43 |
| wgrant | So I removed it. | 04:43 |
| jtv | What branch? | 04:43 |
| wgrant | -if [ "$LPCONFIG" = "$PRODUCTION_CONFIG" ]; then | 04:44 |
| wgrant | - ARCHIVEROOT_PARTNER=/srv/launchpad.net/ubuntu-archive/ubuntu-partner | 04:44 |
| wgrant | - GNUPGHOME=/srv/launchpad.net/ubuntu-archive/gnupg-home | 04:44 |
| wgrant | -else | 04:44 |
| wgrant | - # GNUPGHOME does not need to be set, keys can come from ~/.gnupg. | 04:44 |
| wgrant | - ARCHIVEROOT_PARTNER=/srv/launchpad.net/ppa/ubuntu-partner | 04:44 |
| wgrant | -fi | 04:44 |
| wgrant | That's how it is in devel now. | 04:44 |
| wgrant | The second part of that is broken. | 04:44 |
| jtv | You mean "branch" as in "if"? | 04:44 |
| wgrant | Yes. | 04:44 |
| wgrant | Sorry. | 04:44 |
| lifeless | bah | 04:45 |
| lifeless | wgrant: sinzui is gone, can you show https://bugs.launchpad.net/launchpad/+bug/739961 to him tomorrow ? | 04:45 |
| _mup_ | Bug #739961: person collections in API late evaluate PersonTransferJob <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/739961 > | 04:45 |
| jtv | wgrant: Okay, but does this change really affect the Sources issue? I can see how the _other_ change affects it. | 04:45 |
| wgrant | lifeless: Sure. | 04:45 |
| lifeless | review plox https://code.launchpad.net/~lifeless/launchpad/bug-727540/+merge/54293 | 04:46 |
| wgrant | jtv: I don't recall exactly. But the partner dists move was crashing until I fixed that. | 04:46 |
| jtv | wgrant: your change does mean that ARCHIVEROOT becomes /srv/launchpad.net/ubuntu instead of /srv/launchpad.net/ubuntu-archive/ubuntu as it currently is, doesn't it? | 04:48 |
| wgrant | jtv: Yes. | 04:49 |
| wgrant | Er. | 04:49 |
| jtv | Er. | 04:49 |
| wgrant | Where does cron.publish-ftpmaster get this info? | 04:49 |
| jtv | It duplicates what it finds in the lazr config. | 04:49 |
| wgrant | So it should be fine, then. | 04:49 |
| jtv | Which is one of the things that made this untestable. | 04:49 |
| wgrant | Because it will see config.archivepublisher.root == /srv/launchpad.net/ubuntu-archive | 04:50 |
| jtv | But that's different yet again. | 04:50 |
| jtv | On development systems, by the way, it's all in /var/tmp/archive | 04:51 |
| wgrant | Right. | 04:53 |
| wgrant | But how is it different yet again? | 04:53 |
| wgrant | Assuming that you give cron.publish-ftpmaster config.archivepublisher.root, it should behave the same on prod as the one in devel does. | 04:53 |
| lifeless | StevenK: perhaps you could review https://code.launchpad.net/~lifeless/launchpad/bug-727540/+merge/54293 ? its very simple and has its diff now | 04:55 |
| lifeless | StevenK: I'm going to grab dinner, after that I can perhaps pull your branch down and have a poke for you | 04:55 |
| jtv | wgrant: except that the script duplicates it all in its variables. You just said the production config said /srv/launchpad.net/ubuntu-archive, but you changed the script to use /srv/launchpad.net/ubuntu instead. | 04:58 |
| jtv | This is all so confusing. | 04:58 |
| StevenK | lifeless: So where is the eager loading? | 04:58 |
| wgrant | jtv: The production dists tree lives in /srv/launchpad.net/ubuntu-archive/ubuntu/dists | 04:59 |
| wgrant | jtv: The dev one traditionally lives in /var/tmp/archive/ubuntu/dists | 04:59 |
| jtv | oic! | 04:59 |
| jtv | So then you missed a change: | 05:00 |
| jtv | PUBLISHER_ROOT="${PUBLISHER_ROOT:-/srv/launchpad.net/ubuntu-archive}" | 05:00 |
| jtv | Right? | 05:00 |
| lifeless | StevenK: _members(need_validity..) etc | 05:00 |
| jtv | wgrant: in other words, the "ubuntu-archive" goes into the $PUBLISHER_ROOT instead of being added in ARCHIVEPARENT. | 05:01 |
| jtv | And in fact PUBLISHER_ROOT and ARCHIVEPARENT are the same thing | 05:01 |
| wgrant | jtv: I did enough to make the tests pass. | 05:01 |
| jtv | (which the script previously hid by using $ARCHIVEROOT/..) | 05:01 |
| wgrant | I didn't actually look at what changes you really made. | 05:02 |
| wgrant | Enough to get the tests to pass with a sane path structure, that is. | 05:02 |
| jtv | It's pernicious because there's no way of testing it. Eventually it'll all go; right now I'm concerned with the "chalk outline" that the new version must fill. | 05:02 |
| wgrant | Righ. | 05:03 |
| jtv | Rhymes with "Sigh." :) | 05:03 |
| * jtv looks up production config | 05:03 | |
| wgrant | Also note that Julian's config work will change how this works, but the values should stay the same. | 05:04 |
| wgrant | Just your tests will need to change, if they decide to override configs. | 05:04 |
| jtv | They don't—wouldn't work for external script runs. | 05:15 |
| wgrant | Well, it can. | 05:16 |
| wgrant | We have facilities for that now. | 05:16 |
| wgrant | Indeed you probably should. | 05:16 |
| wgrant | (eg. the librarian and DB fixtures push config overlays then write them to disk) | 05:17 |
| jtv | That may become necessary later as we move this script to python and create more appropriate tests. Then again, at that point it won't involve script runs any more so we should be able to do more in-memory. | 05:23 |
| jtv | wgrant: you were right by the way: the archivepublisher's "root" setting on production is /srv/launchpad.net/ubuntu-archive. | 05:25 |
| wgrant | jtv: Yup. | 05:25 |
| jtv | Thanks for helping me with this. I'm reluctant to drop the ppa stuff until I've got something of a proper test hammered out, but it'd be good to streamline things then. | 05:26 |
| wgrant | Right. | 05:26 |
| jtv | Food. | 05:27 |
| === jtv is now known as jtv-eat | ||
| StevenK | Right, something odd is going on, since I've added the flag manually, and the cron script still can't see it. | 05:35 |
| * StevenK doesn't understand feature flags | 05:39 | |
| lifeless | StevenK: does your script install a flag handler? [jtv's work was in this area] | 05:40 |
| StevenK | lifeless: jtv added it to LaunchpadScript's run() method from what I can see, and my script (through 2 layers of indirection) bases off it | 05:41 |
| StevenK | lifeless: Unless I'm wrong. What's a flag handler? | 05:44 |
| lifeless | sadness | 05:46 |
| lifeless | 1112 timeouts | 05:47 |
| lifeless | StevenK: featurecontroller or whatever | 05:47 |
| StevenK | install_feature_controller(make_script_feature_controller(self.name)) | 05:47 |
| StevenK | Is that enough? | 05:47 |
| StevenK | lifeless: ^ | 05:51 |
| lifeless | yeah, should be | 05:51 |
| lifeless | StevenK: whats the feature controller present when your code does a flag lookup ? | 05:51 |
| StevenK | How do I check that? | 05:51 |
| lifeless | print ? | 05:52 |
| StevenK | Sure, but print *what* ? :-) | 05:52 |
| lifeless | lp.services.features.mumble | 05:52 |
| StevenK | Guessing get_relevant_feature_controller(), which gives None | 05:55 |
| StevenK | lifeless: ^ Which is likely sub-optimal | 05:56 |
| lifeless | StevenK: that is indeed likely to be a problem | 05:58 |
| lifeless | StevenK: is your script threaded? | 05:58 |
| StevenK | lifeless: I have no idea, but I doubt it. | 05:58 |
| lifeless | timeouts top to bottom - ugh, ugh, ugh, fixed fixed fixed ugh ugh in-progress ugh ugh ugh ugh | 06:07 |
| lifeless | StevenK: so, keep spattering prints around - like after install_feature_controller - until you can see what goes wrong | 06:08 |
| huwshimi | ok seriously did someone rename style-3-0.css.in? | 06:10 |
| lifeless | huwshimi: run bin/buildout | 06:10 |
| StevenK | lifeless: So directly after install_feature_controller, it's still None | 06:14 |
| lifeless | so, either you're looking in the wrong place, or that method is failing ;) | 06:15 |
| StevenK | I don't get what install_feature_controller is supposed to do | 06:16 |
| jtv-eat | StevenK: it's a simple setter for the feature controller, though it only applies to the running thread. | 06:19 |
| === jtv-eat is now known as jtv | ||
| StevenK | I'm close to ripping this out for now | 06:19 |
| huwshimi | lifeless: That didn't help. I think it has been renamed. | 06:20 |
| StevenK | I don't understand it, and it seems quite opaque | 06:20 |
| lifeless | huwshimi: delete bin/sprite-util | 06:20 |
| lifeless | huwshimi: then run it | 06:20 |
| StevenK | Or make clean; make | 06:20 |
| jtv | StevenK: let's start by establishing that you're talking to the right feature controller. | 06:21 |
| StevenK | But that's a bigger hammer | 06:21 |
| jtv | StevenK: if get_relevant_feature_controller returns None right after install_feature_controller, then are you sure you didn't pass it a None? | 06:22 |
| StevenK | 'install_feature_controller(make_script_feature_controller(self.name))' is the call | 06:22 |
| StevenK | Which is the line you added to LaunchpadScript | 06:23 |
| jtv | Yes | 06:23 |
| jtv | Oh actually you don't need to install it; make_script_feature_controller calls install_feature_controller. | 06:24 |
| jtv | After which in fact it returns None. | 06:24 |
| StevenK | Oh, so it's broken | 06:24 |
| StevenK | :-P | 06:24 |
| jtv | Yup. | 06:24 |
| jtv | Fixing. | 06:24 |
| StevenK | It's fine, I can do it | 06:25 |
| jtv | You can replace install_feature_controller(make_script_feature_controller(self.name)) with just make_script_feature_controller; or better yet, | 06:25 |
| jtv | make make_script_feature_controller return the controller instead of installing it. | 06:25 |
| StevenK | We don't need the controller, so if it installs it, that's enough | 06:27 |
| StevenK | jtv: This was the failing test for me, so I can just fix the bug in my branch if you wish | 06:27 |
| jtv | True, it's just nice to export just a single function to set the thing. | 06:27 |
| jtv | Needs a test also. | 06:27 |
| StevenK | Which you're working on? | 06:28 |
| jtv | Yes | 06:28 |
| jtv | StevenK: pushing fix | 06:39 |
| jtv | bug 739986 | 06:40 |
| _mup_ | Bug #739986: LaunchpadScript fails to install feature controller <derivation> <feature-flags> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/739986 > | 06:40 |
| huwshimi | lifeless: just fyi that file was renamed | 06:45 |
| jtv | StevenK: care to review? https://code.launchpad.net/~jtv/launchpad/bug-739986/+merge/54299 | 06:46 |
| StevenK | jtv: r=me | 06:48 |
| jtv | thanks | 06:48 |
| jtv | and sorry for the… | 06:48 |
| jtv | oh wait I already said that didn't I | 06:49 |
| StevenK | A few times :-P | 06:49 |
| jtv | possibly not enough :) | 06:49 |
| jtv | This is something that still bothers me about our testing. Quis custodiet ipsos custodies? | 06:49 |
| StevenK | jtv: You'll toss that through ec2? | 06:50 |
| jtv | I was considering it, yes—meanwhile you could just merge it in | 06:50 |
| StevenK | Yup | 06:50 |
| lifeless | huwshimi: it was, but the reason you had a problem was due to a stale built file | 06:51 |
| lifeless | huwshimi: if you fixed it locally by renaming again, you've done it wrong | 06:51 |
| huwshimi | lifeless: I haven't renamed it, I was just getting conflicts within the file and it was renamed and now I'm in a world of hurt with strange diffs, but I think it's completely unrelated to the buildout stuff. I just happened to run into it at the same time. | 06:53 |
| huwshimi | lifeless: I wasn't really expecting to come across the changes and renaming of the files without some kind of warning (like an email) | 06:54 |
| jtv | heh. wgrant, was that you who wrote "I do not care about sources"? Because that seems to be what's bothering a-f now. :) Not sure that we need to fix that though, as long as a Sources file gets generated. | 06:59 |
| wgrant | jtv: I don't recall saying that, but I may have. | 07:00 |
| wgrant | Anyone want to review https://code.launchpad.net/~wgrant/launchpad/restore-archivepublisher-config/+merge/54301? | 07:00 |
| jtv | It just sounded like you somehow. :) | 07:00 |
| wgrant | Probably. | 07:00 |
| jtv | I suppose I owe you one, so sure. | 07:00 |
| wgrant | It's not very difficult :) | 07:01 |
| spm | wgrant: hit jtv for Cake. that way you can start paying us back. /unsubtle-hint | 07:01 |
| wgrant | jtv: (that was cprov) | 07:01 |
| jtv | Cake? | 07:02 |
| wgrant | But yes, it does sound like something I'd say. | 07:02 |
| jtv | wgrant: I just approved without comment. May be a first. | 07:04 |
| jtv | (I did check the bug reference) | 07:04 |
| StevenK | jtv: I'm tossing my branch at ec2. Which means your bug fix might inadvertly land | 07:05 |
| jtv | StevenK: oh woe is us | 07:05 |
| wgrant | jtv: Thanks. | 07:05 |
| jtv | And in case the sarcasm didn't drip quite where everyone can see it, I'll add what BBC teletext page 888 does: "(!)" | 07:06 |
| jtv | (I hope I'm not so much older that I now have to explain what teletext is) | 07:06 |
| StevenK | I'm so tempted to ask, now | 07:06 |
| wgrant | Even I know what Teletext is. | 07:06 |
| wgrant | although only because I didn't know what a button on the old TV did. | 07:06 |
| jtv | StevenK: there you go, ask william just like you would with any soyuz question. | 07:06 |
| jtv | The BBC has excellent subtitling on page 888. | 07:07 |
| jtv | Someone hums half a bar of an ill-remembered melody, off tune, in an anvil factory and the subtitles will tell you it's the 3rd movement from Vivaldi's opus #128 etc. | 07:07 |
| wgrant | jtv: That is surely crucial to the plot. | 07:08 |
| jtv | Surely. | 07:08 |
| jtv | They also use different colours for different characters in films, as I recall. | 07:08 |
| jtv | It was a great help in learning English. | 07:09 |
| lifeless | huwshimi: renames are normally pretty painless; also having short lived branches avoids a lot of pain | 07:10 |
| jtv | StevenK: in replacing cron.publish-ftpmaster, do I need to call getPubConfig on every archive that the script is to work on? | 07:38 |
| wgrant | publish-distro will do that for you. | 07:40 |
| wgrant | But the dists musical chairs probably needs it run before publish-distro. | 07:40 |
| wgrant | But youi'll be moving that into publish-distro soon. | 07:40 |
| jtv | I expect I'll probably need to do some setup before then, yes | 07:40 |
| jtv | Will I? | 07:41 |
| wgrant | I hope so. | 07:41 |
| wgrant | It belongs there. | 07:41 |
| jtv | For now I've been far too busy getting it to run at all. Probably wouldn't have been wise to start hunting for cleanup opportunities too soon. :) | 07:43 |
| jtv | My next step is to pythonify the shell script as-is. | 07:43 |
| wgrant | I'm not sure that Pythonifying it directly is particularly valuable. | 07:44 |
| jtv | It's just one of the steps. | 07:44 |
| jtv | It means that I can use config instead of shell variables that must match the config, for one. | 07:44 |
| jtv | It also means that I can use dedicated temporary directories again, which helps avoid pollution by previous test runs. | 07:45 |
| jtv | And of course it means I can run unit tests and get the results the same day. :) | 07:46 |
| LPCIBot | Project windmill build #85: FAILURE in 1 hr 6 min: https://lpci.wedontsleep.org/job/windmill/85/ | 07:49 |
| lifeless | have I mentioned how much I love that Storm and sqlobject result sets are incompatible with each other ? | 08:00 |
| * jkakar hugs lifeless | 08:01 | |
| jkakar | lifeless: Isn't the problem just that the SQLObject one is incompatible with Storm? ;b | 08:02 |
| lifeless | jkakar: they both ship in the storm tarball >< | 08:02 |
| jkakar | lifeless: I know, I was just being facetious... sorry, coffee hasn't set in yet. | 08:02 |
| lifeless | jkakar: it makes migration tricky | 08:02 |
| lifeless | jkakar: :) | 08:02 |
| lifeless | jkakar: end of long day for me, so the reverse... | 08:02 |
| jkakar | lifeless: Heh | 08:02 |
| spm | heya jkakar! | 08:04 |
| jkakar | spm: Hi! :) | 08:05 |
| jtv | jkakar: so you miss us after all, do you? :) | 08:16 |
| jkakar | jtv: I'm having fun at the new gig, but yes, I do miss you. :) | 08:17 |
| jtv | :) | 08:17 |
| rvba | wgrant: Hi, I'd appreciate a review of https://code.launchpad.net/~rvb/launchpad/db-dds-fix-filter-form-add-parent-name/+merge/54239 | 08:20 |
| * lifeless wonders if http://dev.launchpad.net/ReviewingCodeImports?action=diff&rev1=9&rev2=10 was intended | 08:23 | |
| lifeless | wgrant: I need some blurb aboutthe change for oem | 08:28 |
| wgrant | rvba: Done. | 08:32 |
| === jam1 is now known as jam | ||
| wgrant | lifeless: :( | 08:32 |
| === wgrant changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews | ||
| LPCIBot | Yippie, build fixed! | 08:33 |
| LPCIBot | Project windmill build #86: FIXED in 43 min: https://lpci.wedontsleep.org/job/windmill/86/ | 08:33 |
| lifeless | wgrant: I can just say 'xss hole and escaping blah', but perhaps a little more accuracy would help? | 08:33 |
| rvba | wgrant: thx | 08:33 |
| lifeless | wgrant: if you're doing up an incident report, just make a clear summary, and I'll copy that across - avoids you duplicating effort | 08:34 |
| lifeless | lib/lp/bugs/tests/../doc/bugnotification-sending.txt", line 1260, in bugnotification-sending.txt | 08:34 |
| lifeless | ^ db-devel failure. | 08:34 |
| lifeless | ring any bells? | 08:34 |
| lifeless | ah | 08:35 |
| lifeless | - Matching filters: Allow-comments filter | 08:35 |
| lifeless | ? ^ ^ ^^ | 08:35 |
| lifeless | + Matching subscriptions: Allow-comments filter | 08:35 |
| lifeless | ? ^^^^^^ ^ ^^^ | 08:35 |
| lifeless | someone didn't use ec2 :) | 08:35 |
| lifeless | (or ran into a landing race I guess) | 08:36 |
| wgrant | lifeless: Merge issue. Fix already landed. | 08:40 |
| wgrant | lifeless: https://wiki.canonical.com/IncidentReports/2011-03-22-LP-unescaped-json, but the summary is not very good. | 08:45 |
| henninge | jtv: Hi! | 08:46 |
| jtv | hi henninge | 08:46 |
| === almaisan-away is now known as al-maisan | ||
| henninge | jtv: I picked up bug 605924 as you may have noticed. I just commented on what I plan to do. | 08:47 |
| _mup_ | Bug #605924: Clean up IHasTranslationTemplates <lp-translations> <tech-debt> <Launchpad itself:In Progress by henninge> < https://launchpad.net/bugs/605924 > | 08:47 |
| henninge | if you are interested. | 08:47 |
| * jtv has a look | 08:47 | |
| jtv | henninge: looks good—I agree that the hard part is to find all uses and make sensible decisions for them. The tests probably aren't going to find all of those, but that's no excuse for ignoring the issue forever. | 08:50 |
| henninge | jtv: well, I am picking it up because it is hindering me in using this properly. | 08:50 |
| jtv | That's as good a reason as any other, isn't it? :) | 08:51 |
| henninge | well, it certainly raises its priority ... or urgency? whatever | 08:54 |
| lifeless | wgrant: cool; are you forcing a build? | 08:56 |
| wgrant | lifeless: It's already building again. | 08:56 |
| lifeless | cool | 08:56 |
| wgrant | Because there was the testfix rev in the queue. | 08:56 |
| adeuring | good morning | 08:59 |
| jtv | morning adeuring | 09:00 |
| jml | lifeless: hello | 09:00 |
| adeuring | hi jtv | 09:00 |
| lifeless | jml: hi | 09:01 |
| jml | lifeless: skype? | 09:02 |
| lifeless | jml: aye | 09:02 |
| jml | lifeless: hello, I can now hear you | 09:03 |
| jml | lifeless: Total: 231 (+42, -48 since 2011-03-15) | 09:07 |
| wgrant | lifeless: Thanks. | 09:08 |
| lifeless | wgrant: de nada, thank you! | 09:08 |
| poolie | is staging down? | 09:09 |
| poolie | i'm getting a 504 gateway timeout trying to make api calls against it | 09:10 |
| poolie | it might be just me | 09:10 |
| wgrant | staging is down, yes. | 09:10 |
| wgrant | Fix landed. | 09:10 |
| poolie | thanks | 09:11 |
| wgrant | We might be able to get it going again mid-morning tomorrow. | 09:11 |
| wgrant | Maybe. | 09:11 |
| poolie | is there any point filing a bug saying the api error is less clear than the web ui one? | 09:14 |
| lifeless | nope | 09:14 |
| poolie | this seems like another reason to make lplib default away from staging | 09:22 |
| bigjools | morgen | 09:22 |
| wgrant | Morning bigjools. | 09:22 |
| wgrant | bigjools: I've restored those archivepublisher config schema entries in db-devel, so the configs work again. | 09:23 |
| bigjools | wgrant: why? | 09:23 |
| wgrant | bigjools: staging broke. | 09:23 |
| bigjools | yes, it was broke before and Chex cowyboyed it | 09:24 |
| wgrant | Also because having to merge configs in lockstep with deployments sucks. | 09:24 |
| wgrant | We're going to have to cowboy it every time it updates... | 09:24 |
| bigjools | grar | 09:24 |
| wgrant | Anyway, fixed now. | 09:24 |
| bigjools | I detest this config system | 09:24 |
| wgrant | I just have to remove the entries right after the next deployment. | 09:24 |
| bigjools | yes, but it's hassle and pain and annoyance | 09:24 |
| wgrant | It is. | 09:25 |
| StevenK | Bloody hell. If it isn't the backup killing garbo-hourly, it's a vacuum | 09:26 |
| bigjools | wgrant: nice security fix earlier :) | 09:26 |
| wgrant | bigjools: Yeah :/ | 09:26 |
| bigjools | you'd think it having been broken once before there'd be a test case | 09:26 |
| wgrant | I plan to add one tomorrow. | 09:26 |
| wgrant | Also I might upgrade our simplejson and fix it properly. | 09:28 |
| wgrant | Since IE prevents any sensible fix. | 09:28 |
| bigjools | heh, that explains your FB update earlier | 09:30 |
| wgrant | I mean, XHTML was only standardised 11 years ago. | 09:32 |
| poolie | wow, hooray for bug expiry | 09:38 |
| LPCIBot | Project db-devel build #478: STILL FAILING in 5 hr 4 min: https://lpci.wedontsleep.org/job/db-devel/478/ | 09:38 |
| lifeless | jml: 11 / 18 Product:+code-index | 09:41 |
| lifeless | jml: https://code.qastaging.launchpad.net/++profile++show/launchpad | 09:42 |
| lifeless | jml: 06699-12526@SQL-launchpad-main-slave SELECT DISTINCT BugBranch.branch FROM Bug, BugBranch WHERE BugBranch.branch IN (24637, 34755, 34756, 352362, 423464, 423252, 438596, 423710, 438533, 28862, 421710, 425429, 425609, 424278, 422318, 423317, 423707, 423704, 422533, 421039, 423618, 422191, 423555, 423341, 423342, 423273, 423359, 423465, 419565, 423403, 423337, 30466, 421067, 422299, 421762, 422907, 422741, 422712, 319807, 422 | 09:43 |
| lifeless | is 6000ms | 09:43 |
| lifeless | jml: https://lp-oops.canonical.com/oops.py/?oopsid=1906G1635#repeatedstatements | 10:00 |
| === gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | firefighting: - | On call reviewer: gmb | https://code.launchpad.net/launchpad-project/+activereviews | ||
| === almaisan-away is now known as al-maisan | ||
| lifeless | jml: https://lp-oops.canonical.com/oops.py/?oopsid=1906G1635#statementlog - query 39 and 40 appear identical to me | 10:42 |
| lifeless | jml: both are 'bmps where the source is for this product and both branches are visible | 10:42 |
| lifeless | jml: I think we could get a little fuzzy and use 'the source is for this product and the source is visible' - because you cannot /create/ a bmp targeting a branch you cannot see: | 10:43 |
| lifeless | some person subscribed to the source might see the *count* of a bmp they cannot otherwise see | 10:44 |
| lifeless | but would that matter? anonymous users wouldn't get wrong data, nor would authenticated users with no access to the source branches | 10:44 |
| lifeless | doing that makes the query run in 70ms | 10:45 |
| sladen | sorry to bother people---I've been searching for about 15 minutes and haven't turned it up yet | 10:48 |
| sladen | I've had an email passed to me about visual/side-by-side diffing in code-hosting of non-code | 10:48 |
| sladen | along similiar lines to https://github.com/cameronmcefee/Image-Diff-View-Modes/commit/8e95f70c9c47168305970e91021072673d7cdad8 | 10:49 |
| sladen | I remember this being discussed at length ~3 years ago, but I haven't turned up any blueprints, mailing list posts or even bugs against launchpad itself | 10:49 |
| jml | lifeless: looking... | 10:50 |
| sladen | ah https://answers.launchpad.net/bzr/+question/121049 | 10:50 |
| sladen | "Can Bazaar meet requirements for game-development workflows?" | 10:51 |
| lifeless | sladen: yeah, discussed on canonical-launchpad and canonical-bazaar too:) | 10:52 |
| sladen | lifeless: my apologies. Guess I need to join those to read the archives | 10:53 |
| lifeless | jml: actually, I've got a 130ms plan | 10:56 |
| lifeless | jml: with half the cost estimate | 10:56 |
| jml | lifeless: nice | 10:56 |
| lifeless | https://bugs.launchpad.net/launchpad/+bug/736008 | 10:57 |
| _mup_ | Bug #736008: Product:+code-index timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/736008 > | 10:57 |
| deryck | Morning, all. | 11:01 |
| === henninge_ is now known as henninge | ||
| henninge | danilos, jtv: Any idea why we have this in our code (for productseries and distroseries) ? http://paste.ubuntu.com/583755/ | 11:29 |
| henninge | danilos, jtv: I mean, why override the usage of the parent object? | 11:29 |
| jtv | ah | 11:29 |
| henninge | Asside from the fact that we get a nice loop here | 11:30 |
| henninge | because the template cound is dependend on the usage ... | 11:30 |
| jtv | Ah, that's fun… | 11:30 |
| jtv | In any case it seems like a strange fallback. | 11:31 |
| jtv | It was decided at the time that there is basically no usage as long as there are no templates, and now we do allow that again. | 11:31 |
| henninge | jtv: I understand the "usage" more like an expression of the maintainers intend. | 11:36 |
| jtv | That was historically the idea behind official_rosetta, yes. | 11:36 |
| henninge | well, the question is what are the consequences of the usage value? | 11:37 |
| jtv | But in UI terms, I thought the idea had shifted (as part of the cross-app "usage" renovation) to "there is a stated intent and there is a usable setup." | 11:37 |
| henninge | ok, but this is doing "a stated intend OR a usable setup" | 11:38 |
| henninge | which is strange. | 11:38 |
| henninge | I'd rather have LP say "The user wants to use launchpad for translations but has not yet configured it fully." | 11:39 |
| henninge | Also, the presence of templates does not imply "LAUNCHPAD" usage, it might also be external templates being mirrored in. | 11:39 |
| henninge | through a branch | 11:39 |
| henninge | which is actually a common setup we are trying to achieve for upstream message sharing. | 11:40 |
| jtv | I agree with your desire, but I'd talk to sinzui and… was it jcsackett who re-did the usage flags? | 11:40 |
| henninge | ok | 11:40 |
| henninge | thanks, jtv | 11:40 |
| henninge | jtv: oh, I just saw that there is wrong line in my paste | 11:41 |
| jtv | ? | 11:41 |
| henninge | line 5 | 11:41 |
| henninge | I hope you were not discussing that? ;-) | 11:42 |
| jtv | Now I have to look again… | 11:42 |
| henninge | Here is the correct version that reflects the current code: http://paste.ubuntu.com/583761/ | 11:42 |
| jtv | henninge: oh, that was so weird my eyes just skipped over it. | 11:43 |
| henninge | phew | 11:43 |
| henninge | danilos: ^ in case you read the backscroll | 11:44 |
| jtv | henninge: and "usage" is "self.usage"? | 11:45 |
| henninge | argh | 11:46 |
| henninge | jtv: this is the correct paste. really now. http://paste.ubuntu.com/583762/ | 11:46 |
| henninge | usage = self.product.translations_usage | 11:46 |
| henninge | sorry for the confusion | 11:46 |
| jtv | Ah, that was the sort of line my eyes assumed must be there in previous versions. :) | 11:46 |
| === al-maisan is now known as almaisan-away | ||
| benji | leonardr: did my info help with your start up event problem? | 12:27 |
| leonardr | benji: yes, thanks! | 12:27 |
| benji | good | 12:27 |
| === matsubara-afk is now known as matsubara | ||
| jcsackett | henninge: i see that jtv recommends talking with me and/or sinzui? something about translations_usage? | 12:59 |
| bigjools | TypeError: getPublishedSources() got an unexpected keyword argument 'status' | 12:59 |
| * bigjools blinks | 12:59 | |
| abentley | leonardr: enabling the IJSONRequestCache.objects functionality for anonymous users causes xx-bug-obfuscation.txt to fail. I think this mechanism may be too revealing. | 13:05 |
| leonardr | abentley: what's the failure? | 13:05 |
| abentley | leonardr: http://pastebin.ubuntu.com/583778/ | 13:05 |
| === almaisan-away is now known as al-maisan | ||
| leonardr | abentley: so the problem is not that None gets into the cache, it's that something gets into the cache that shouldn't | 13:06 |
| abentley | leonardr: yes. | 13:07 |
| leonardr | i don't think "don't show the cache at all" is a winning long-term strategy. that cache is becoming more and more important | 13:07 |
| leonardr | the code that populates the cache needs to learn some discretion | 13:07 |
| leonardr | do you agree? | 13:07 |
| abentley | leonardr: no, I don't. | 13:07 |
| abentley | leonardr: I think it suggests that we should be specific about the data we pass on. | 13:08 |
| === al-maisan is now known as almaisan-away | ||
| leonardr | you may not agree with me, but i agree with you | 13:08 |
| abentley | leonardr: rather than passing whole objects. | 13:08 |
| abentley | leonardr: We should just pass the specific attributes we need. | 13:08 |
| bigjools | :q | 13:08 |
| leonardr | if we had the expand/filter system in place we could exploit that | 13:10 |
| leonardr | what attributes do you want to pass? | 13:10 |
| abentley | leonardr: For ProductSeries, title, web link, autoimport status, project link. For Branch, unique_name, web link. For Project, translations_usage, title, web link. | 13:13 |
| leonardr | abentley: i think you may have uncovered a larger bug. presumably the anonymous user is seeing the uncensored email address in the representation of the bug | 13:13 |
| leonardr | what happens if the anonymous user just requests that bugtask through the web service? | 13:13 |
| abentley | leonardr: no idea. | 13:15 |
| leonardr | abentley: i'm going to speak with the authority of someone who won't be working here next week :) | 13:15 |
| leonardr | putting entire objects into the cache when you don't need the whole thing is inefficient, but it should not cause data breaches | 13:16 |
| leonardr | there's something wrong with the way the cache is populated that's causing xx-bug-obfuscation to fail | 13:16 |
| abentley | leonardr: the email address is appearing in the bug description. | 13:17 |
| leonardr | right. but why is launchpad giving an uncensored bug description to an anonymous user? either the censoring isn't happening when a json representation is requested, in which case the web service as a whole is leaking data | 13:17 |
| leonardr | or when we make an internal request for the json representation of the bug, we are for whatever reason escalating the user's privileges | 13:18 |
| leonardr | so they see an uncensored version | 13:18 |
| leonardr | either way, refusing to show the cache at all is just papering over the problem | 13:19 |
| === almaisan-away is now known as al-maisan | ||
| abentley | leonardr: if the privileges are being escalated, they're being escalated after the tal condition used to be evaluated, which is very late. | 13:19 |
| abentley | leonardr: Well, I suppose they could be escalated and then dropped by the time the tal is evaluated. But the template knows we've got an unauthenticated user. | 13:20 |
| henninge | jcsackett: Hi, yes about its intended meaning. | 13:33 |
| henninge | jcsackett: I understand the usage flags to reflect the intention of the maintainer of how to use that particular part of LP for their project. | 13:34 |
| jcsackett | henninge: right. as i recall, we had some confusion of what best reflected that for translations, as translations has quite a few more "nobs" than other parts of launchpad. | 13:35 |
| jcsackett | at least when we initially put the enums into use, translations used the enums plus some other information to determine what would be showed. | 13:35 |
| * jcsackett doesn't know what's become of that since. | 13:36 | |
| henninge | jcsackett: I was particularly surprised to find this in the code http://paste.ubuntu.com/583762/ | 13:36 |
| henninge | jcsackett: ok, I guess I can feel free to redefine that, then ... ;-) | 13:36 |
| dpm | hi jcsackett, bug 740153 looks more like a LP Translations bug to me (possibly related to message sharing?) than a synaptic bug. Shouldn't it be reassigned to LP? | 13:37 |
| _mup_ | Bug #740153: Translations skewed for synaptic <synaptic> <ubuntu> <upgrade> <NULL Project:Invalid> <synaptic (Ubuntu):New> < https://launchpad.net/bugs/740153 > | 13:37 |
| jcsackett | dpm: that could be. i may have misunderstood the complaint. | 13:37 |
| dpm | jcsackett, the reported was saying that the translations in LP were overwritten by others done a long time ago, which I'd guess couldn't have happened in Synaptic itself, but in LP | 13:38 |
| jcsackett | dpm: ah, yes. okay, that should be targeted back to LP. | 13:39 |
| jcsackett | henninge: correct. there was some ongoing work on translations when we were phasing that in (perhaps recife?) that was going to require changes to the translations_usage property. | 13:39 |
| jcsackett | does that jive with what concerns you? | 13:40 |
| henninge | jcsackett: possibly. | 13:49 |
| henninge | jcsackett: I am trying this out here to see what happens. | 13:49 |
| dpm | jcsackett, would you mind reassigning it to LP when you've got a minute? I don't seem to be able to make it, I get a "Too many matches. Please try to narrow your search." when trying to change the product | 13:51 |
| jcsackett | dpm: i'm getting the same issue. :-P i'll reassign it soon. | 13:51 |
| dpm | jcsackett, ah, and I thought you launchpadders had superpowers to overcome the issue :P | 13:52 |
| jcsackett | dpm: we have many superpowers. in this case, the super power of being very patient with launchpad may be most applicable. :-) | 13:53 |
| dpm | :-) | 13:53 |
| henninge | abentley, adeuring: I will relocate quickly now, might be a bit late for the stand-up. | 13:53 |
| jcsackett | dpm: and we're good. | 13:58 |
| jcsackett | thanks for catching my mistake. :-) | 13:58 |
| dpm | jcsackett, awesome, thanks! | 13:58 |
| bac | hi deryck, can i quiz you about some structural subscription minutiae? | 14:09 |
| === leonardr changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | firefighting: - | On call reviewer: gmb, leonardr | https://code.launchpad.net/launchpad-project/+activereviews | ||
| deryck | bac: you can, but I'm about to do a call with abentley. Can we chat after that? | 14:13 |
| bac | deryck: sure | 14:13 |
| deryck | ok, cool. I'll ping when I'm free. | 14:13 |
| sinzui | henninge: danilos: can either of you assist me in answering https://answers.launchpad.net/launchpad/+question/148141 | 14:18 |
| henninge | sinzui: looking | 14:19 |
| henninge | sinzui: unfortunately he is right. That feature has been removed. | 14:23 |
| henninge | unfortunate for his project, that is. | 14:23 |
| sinzui | henninge: Why did we remove this for projects. I think I understand the issue for Ubuntu | 14:25 |
| henninge | sinzui: I am not sure, actually. It may be pure oversight. | 14:25 |
| sinzui | henninge: Should I report a bug asking that the new/translated status for upstreams be restored for projects? | 14:30 |
| henninge | sinzui: Yes, at least to have a point of discussion why this was done. | 14:32 |
| sinzui | okay. Thank you | 14:33 |
| LPCIBot | Project db-devel build #479: STILL FAILING in 5 hr 1 min: https://lpci.wedontsleep.org/job/db-devel/479/ | 14:39 |
| dpm | sinzui, I've just caught the conversation re: new/translated status in projects. When you file the bug, would you mind subscribing me or pointing me to it? I'd be interested in following the discussion. Thanks! | 14:48 |
| adeuring | gmb: leonardr: could one of you please review this MP: https://code.launchpad.net/~adeuring/launchpad/no-package-translation-uploads-when-sharing/+merge/54356 ? | 14:48 |
| leonardr | i got it | 14:48 |
| sinzui | dpm bug 740225 | 14:49 |
| _mup_ | Bug #740225: The differences between New and Translated for upstreams was removed <rosetta-imports> <upstream-translations-sharing> <Launchpad itself:New> < https://launchpad.net/bugs/740225 > | 14:49 |
| jam | I just confirmed another XSS vulnerability in loggerhead for bug #740142 | 14:49 |
| jam | how do we roll out fixes for that sort of thing? | 14:49 |
| dpm | thanks sinzui | 14:49 |
| adeuring | leonardr: thanks! | 14:51 |
| jam | I'd also like to avoid pushing the fix making it public | 14:52 |
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| leonardr | adeuring: r=me | 15:03 |
| adeuring | leonardr: thanks! | 15:03 |
| === al-maisan is now known as almaisan-away | ||
| === Ursinha-afk is now known as Ursinha-lunch | ||
| deryck | bac: about ready now. voice or chat? | 15:37 |
| bac | deryck: mumble might be quickest | 15:37 |
| deryck | ok. firing it up.... | 15:38 |
| deryck | bac: what room? | 15:40 |
| deryck | bac: just drag me around ;) | 15:40 |
| === salgado is now known as salgado-lunch | ||
| === beuno is now known as beuno-lunch | ||
| === matsubara is now known as matsubara-lunch | ||
| === Ursinha-lunch is now known as Ursinha | ||
| === beuno-lunch is now known as beuno | ||
| === salgado-lunch is now known as salgado | ||
| === deryck is now known as deryck[lunch] | ||
| jcsackett | sinzui: do you know much about how security adapters work? | 17:15 |
| jcsackett | or, anyone, same question? i'm having trouble getting an adapter (or really a new security.py file) working. | 17:19 |
| bigjools | we really need to fix the ajax-forms-lose-data problem | 17:20 |
| bigjools | just got burned big time | 17:20 |
| sinzui | jcsackett: I do now quite a bit | 17:21 |
| bigjools | by clicking a non ajax find-person link on the bug filing page :/ | 17:21 |
| sinzui | jcsackett: is this about adaption to IFAQTarget or IQuestionTarget | 17:21 |
| jcsackett | it's a security adapter for IQuestion. | 17:21 |
| jcsackett | sinzui ^ | 17:21 |
| * sinzui starts mumble | 17:21 | |
| * jcsackett starts it too. | 17:22 | |
| jcsackett | sinzui: i suspect you cannot hear me. i cannot hear you either. :-P | 17:23 |
| * sinzui stabs mumble | 17:24 | |
| jcsackett | i heard you. | 17:24 |
| jcsackett | i will restart mumble as well. | 17:24 |
| jcsackett | sinzui: unrelated, are there still long term plans to deprecate polls (there's a question in #launchpad) | 17:25 |
| sinzui | jcsackett: I see the mic setting went missing. I was there 18 hours ago | 17:25 |
| sinzui | They are deprecated. We do not support them. There exist only for the Ubuntu community | 17:25 |
| jcsackett | sinzui: i can hear you. | 17:26 |
| jcsackett | but clearly you cannot hear me. :-P | 17:27 |
| sinzui | no I cannot | 17:27 |
| jcsackett | hm. | 17:27 |
| jml | abentley: I have some questions about the TwistedJobRunner | 17:41 |
| abentley | jml: shoot | 17:42 |
| jml | abentley: in getTaskSource, why does the producer exhaust the iterReady() iterator before the loop begins? | 17:42 |
| jml | abentley: hmm. actually another way of putting this is, what are you trying to get out of using PollingTaskSource? | 17:43 |
| abentley | jml: I believe that's so that it runs for a finite time, instead of pulling jobs infinitely. | 17:43 |
| abentley | jml: PollingTaskSource was existing Twisted code for doing this kind of thing. | 17:45 |
| jml | abentley: I think we can achieve the same effect more simply by using DeferredSemaphore instead of PollingTaskSource and ParallelLimitedTaskConsumer, but I'm a little bit hesitant because I don't see many tests. | 17:45 |
| LPCIBot | Project windmill build #89: FAILURE in 1 hr 17 min: https://lpci.wedontsleep.org/job/windmill/89/ | 17:46 |
| jml | abentley: also, that reminds me, TwistedJobRunner uses ParallelLimitedTaskConsumer with a hard-coded maximum number of 1 task at a time. What's the reason behind that? | 17:46 |
| bigjools | lifeless: and as if by magic, bug 740250 appears | 17:47 |
| abentley | jml: The idea was that we could relax the maximum when we felt that would improve performance. | 17:47 |
| _mup_ | Bug #740250: Timeout accepting packages <Launchpad itself:New> < https://launchpad.net/bugs/740250 > | 17:47 |
| jml | abentley: fair enough. | 17:47 |
| jml | abentley: last question, I think... | 17:47 |
| jml | abentley: I think I've isolated the intermittent failure in TestTwistedJobRunner.test_timeout. It comes from ampoule killing the job before the custom signal handler is installed | 17:48 |
| abentley | I don't think that's possible. | 17:48 |
| jml | abentley: I can prove it with science. | 17:49 |
| abentley | the signal handler is installed when the first job runs, right? | 17:49 |
| jml | hmm. interesting point. | 17:50 |
| jml | OK. I can say with much greater confidence that if I reduce the lease_length in the test from 1 to a very small number, like 0 or 0.01, then the "intermittent" failure becomes deterministic. | 17:51 |
| jml | abentley: is it guaranteed to re-use the same process? | 17:51 |
| abentley | jml, that's what it's supposed to do, and I didn't see anything to make me believe otherwise. | 17:52 |
| jml | abentley: good answer :) | 17:52 |
| abentley | jml: I haven't dug through ampoule's internals thoroughly, and it's been a while since I looked at them at all. | 17:53 |
| jml | abentley: I had a bit of a poke. There's definitely something racy going on with the lease_length (ampoule's "deadline"). | 17:54 |
| abentley | jml: Okay, IIRC 0 is treated completely stupidly. | 17:55 |
| abentley | jml: I don't remember the details. | 17:55 |
| jml | abentley: it's a bit obscured by the abstraction in job. | 17:55 |
| jml | abentley: ok. I'll keep poking. | 17:55 |
| jml | abentley: are there tests for the TwistedJobRunner other than TestTwistedJobRunner? | 17:55 |
| abentley | jml: There are tests for the branch_merge_proposal_jobs script, which uses it. | 17:56 |
| jml | abentley: thanks. I'll use those as backup. | 17:56 |
| bigjools | g'night everyone | 17:59 |
| jml | bigjools: g'night. | 18:00 |
| abentley | jml: I wonder if setting the value to a very small number would cause the deadlineCall to fire before the callRemote? | 18:03 |
| jml | abentley: that does happen. Although interestingly, the failure in the test is that the job *does* complete successfully (you can tell because the wait goes up to 30s+) | 18:03 |
| abentley | jml: That's the failure case I hadn't been able to pin down-- the unexpected success. | 18:04 |
| jml | abentley: I guess I'll instrument ampoule & see what happens. | 18:05 |
| abentley | jml: I think I was wrong about the 0 handling, or else it was improved. In any case, that's the timeout handling, and we're using deadlines, IIRC. | 18:08 |
| === deryck[lunch] is now known as deryck | ||
| jml | oh. | 18:14 |
| jml | hm. | 18:14 |
| jml | abentley: it uses the same mechanism, afaict. | 18:14 |
| jml | http://paste.ubuntu.com/583909/ | 18:15 |
| abentley | jml: well, similar, but without special-casing 0. | 18:15 |
| jml | right. | 18:15 |
| abentley | leonardr: I'm writing some code that wants to treat an object the same whether it's from the LP.cache or retrieved from the web service. | 18:35 |
| leonardr | abentley: that's a good place to be going. what problem are you having? | 18:35 |
| abentley | leonardr: But WS objects use .get('foo') and LP.cache objects use ['foo']. | 18:36 |
| leonardr | probably because ws objects are wrapped in a LP.Entry class (or whatever it's called), and LP.cache objects are just data structures | 18:36 |
| abentley | leonardr: right. | 18:37 |
| leonardr | you should be able to wrap the data structure yourself, and i'd even say that should be done automatically | 18:37 |
| abentley | leonardr: sounds reasonable. | 18:38 |
| leonardr | benji, i've once again reached the point where i can't stand to work on this multiversion stuff anymore. do you want to talk about filter/expand? | 18:57 |
| benji | leonardr: sure, say 10 minutes from now? | 18:59 |
| leonardr | ok | 18:59 |
| jml | abentley: OK. I've got it figured out. http://paste.ubuntu.com/583931/ | 19:01 |
| jml | abentley: the signal is being sent before the callRemote call... | 19:01 |
| jml | (as you said) | 19:01 |
| jml | abentley: what this means is that the signal handler is triggered, raises an error, and then ... well, who cares? it's not going to terminate the process. | 19:02 |
| abentley | jml: Cool. That's great you were able to track it down. | 19:03 |
| abentley | jml: so we need to tweak ampoule so it doesn't try to kill processes until they have launched? | 19:04 |
| jml | abentley: not sure. in this case the process has launched, it's just that the command isn't running. tbh I'm not sure by what mechanism an exception that is raised in a signal handler is propagated out. | 19:04 |
| jml | abentley: experimenting now... | 19:04 |
| jml | *maybe* something to do with hooking up the OOPS system to the Twisted log? | 19:08 |
| jml | errors raised in sighup handlers while reactor is running get treated as Unhandled errors, I think. | 19:09 |
| leonardr | benji: i'd like to start the chat in irc if that's ok | 19:12 |
| === matsubara-lunch is now known as matsubara | ||
| benji | leonardr: sounds good | 19:12 |
| leonardr | i'm vacillating on having it here vs. in another room where we won't flood everyone else's conversations | 19:13 |
| abentley | jml: I see what you mean. | 19:13 |
| leonardr | like the defunct #launchpad-meeting | 19:13 |
| leonardr | anyway, let me try to find the stuff i wrote on this before | 19:14 |
| leonardr | here we go: https://dev.launchpad.net/Foundations/Webservice/DraftProposal | 19:16 |
| leonardr | i think the only thing not mentioned in that document | 19:17 |
| benji | leonardr: we can do it in PM, or we can just fabricate a chan., like #expand-and-filter | 19:17 |
| leonardr | let's do it in pm, i don't think there's all that much to discuss now that i've found that document | 19:18 |
| leonardr | since it never got much further than that document | 19:18 |
| benji | k | 19:18 |
| leonardr | basically i just think this is really important to the future of the web service and i don't want it to fall through the cracks when i leave | 19:18 |
| benji | yep, agreed | 19:19 |
| jml | abentley: so actually, it's just that the exception is raised in whatever code happens to be running at the time. maybe we can store some state ("hey, we got HUPped") and then raise during runJob if we see that state? | 19:25 |
| abentley | jml: The exception being TimeoutError? | 19:29 |
| jml | abentley: yes, or indeed anything that 'handler' might raise. | 19:30 |
| abentley | jml: And if the job hasn't started, that would be raised in ampoule code, I guess. | 19:30 |
| abentley | jml: And then, for some reason, it's not causing the process to terminate. | 19:31 |
| jml | abentley: sort of. It will be raised as an unhandled error, because it's during the reactor.run() in BOOTSTRAP | 19:31 |
| jml | abentley: e.g. http://paste.ubuntu.com/583943/ (simplified version) | 19:31 |
| jml | the reactor keeps running | 19:31 |
| jml | and whatever things were set up to listen to connections are still set up | 19:32 |
| jml | in this case, the AMP protocol handlers | 19:32 |
| abentley | jml: The reactor in the child process keeps running? | 19:32 |
| jml | abentley: yes. | 19:32 |
| jml | abentley: if the SIGHUP happens between jobs, it's only the child process that ever learns about the raised error. | 19:32 |
| abentley | jml: I guess your solution makes some sense, but it doesn't feel satisfying. What if no job ever gets run in the child? | 19:35 |
| jml | abentley: I agree that it doesn't feel satisfying. I don't know what would happen in that case, or what we desire to happen. | 19:36 |
| jml | abentley: I guess the timeout/deadline/lease is tied to the job rather than the child process. | 19:36 |
| jml | abentley: so maybe it wouldn't matter. | 19:36 |
| abentley | jml: true. | 19:36 |
| abentley | jml: What about the case where the timeout fires after the job completes, but before the next is dispatched? | 19:37 |
| jml | abentley: then in the simplest implementation, the next job would "time out" instantly | 19:37 |
| jml | or at least, that's what it would look like. | 19:38 |
| jml | I'm also worried about making timeout code too complex. It's supposed to be something you can rely on when other things fail. | 19:38 |
| abentley | jml: Fully agreed. | 19:39 |
| abentley | jml: Can we tweak this so that the child always dies when we raise TimeoutError? | 19:39 |
| jml | abentley: probably. it's easy enough to sys.exit or reactor.stop or something. how does ampoule handle dead children? | 19:39 |
| jcsackett | sinzui: can i set you as help contact in #launchpad? | 19:40 |
| jml | even if we stopped the process, we'd have to figure out how to tell the parent that we did it because of a timeout. I guess we have OOPS logging available to us from BaseJobRunner. | 19:41 |
| abentley | jml: I don't know how it handles dead children, but it expects timeouts to kill children, so it should expect this. | 19:43 |
| jml | abentley: OK. I'll give it a try, see how it goes. | 19:44 |
| jml | relatedly, I'd like to have a few more direct unit tests for this code. | 19:44 |
| jml | not tonight though. | 19:44 |
| LPCIBot | Yippie, build fixed! | 19:45 |
| LPCIBot | Project db-devel build #480: FIXED in 5 hr 5 min: https://lpci.wedontsleep.org/job/db-devel/480/ | 19:45 |
| abentley | jml: I guess at the time it seemed like there weren't a lot of units to test. | 19:45 |
| jml | abentley: I know the feeling. maybe there aren't, but after debugging this for a while I'd like to give it a try. | 19:47 |
| jml | abentley: we'll have to do some work to translate the death into a TimeoutError, but I think it can be done | 19:51 |
| jml | but that's enough from me for this evening | 19:52 |
| jml | abentley: thanks for the help. | 19:52 |
| abentley | jml: no problem. | 19:52 |
| abentley | jml: good to get some fresh eyes on this. | 19:52 |
| jml | g'night all. | 20:11 |
| sinzui | jcsackett: I am so sorry. I forgot :( | 20:12 |
| jcsackett | sinzui: no worries, it's been a quiet day. | 20:12 |
| jcsackett | i just didn't want to switch you over if you were busy. | 20:13 |
| bac | hi sinzui | 20:58 |
| sinzui | bac | 21:04 |
| wallyworld_ | benji: hi. did you get a chance to look at my lazr restful enhancement? i was hoping to check with leonard but he's not around atm it seems | 21:05 |
| benji | wallyworld_: yep I looked at it and didn't see anything bad jump out at me, I'd like to give it some more thought and get back to you tomorrow, how's that? | 21:10 |
| bac | hi sinzui | 21:10 |
| sinzui | hello | 21:10 |
| bac | i wanted to ask you about the new hidden menu items and the use of the invisible-link class | 21:11 |
| bac | it doesn't seem to do what i thought it did, i.e. make the link invisible | 21:11 |
| wallyworld_ | benji: that's fine thanks. i'll continue on with a branch to use the new stuff to fix the actual bug and we can revisit when you are ready | 21:11 |
| bac | sinzui: was i correct in understanding the link would be present but invisible until i removed the class in JS? | 21:12 |
| sinzui | bac: yes | 21:13 |
| bac | hmm, ok | 21:13 |
| sinzui | bac: let me look for a page with such as link | 21:13 |
| LPCIBot | Yippie, build fixed! | 21:37 |
| LPCIBot | Project windmill build #90: FIXED in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill/90/ | 21:37 |
| lifeless | wgrant: ping me when you're back | 22:09 |
| lifeless | wgrant: back yet? | 22:55 |
| wgrant | lifeless: Hi. | 23:23 |
| lifeless | wgrant: so, why is the id desc sort important? | 23:24 |
| wgrant | lifeless: For the POST? It's probably not; that query shouldn't be happening at all. | 23:25 |
| wgrant | For the GET... what other order is there? | 23:25 |
| wgrant | Apart from date_created, which is the same issue. | 23:25 |
| lifeless | wgrant: so I proposed distroseries desc, status desc, archive desc, PackageUpload.id DESC | 23:25 |
| lifeless | wgrant: distroseries and status are constants | 23:26 |
| lifeless | so this is known as 'noddy fool the planner stuff' | 23:26 |
| lifeless | archive has two values - 1, 534 | 23:26 |
| wgrant | It's fooling the planner into making a bad decision. | 23:26 |
| lifeless | wgrant: good decision | 23:26 |
| wgrant | Bad, because the ID sort is unindexed in that case. | 23:27 |
| wgrant | This will probably exacerbate timeouts in the DONE case. | 23:27 |
| lifeless | wgrant: huh, no, id is in the index | 23:27 |
| wgrant | Oh, so it doesn't use it even with the full index? | 23:27 |
| wgrant | I suspect your index is buggy. | 23:27 |
| wgrant | packageupload(archive, distroseries, status, id) is what I think is ideal. | 23:28 |
| lifeless | create index packageupload__distroseries__status__archive__idx on packageupload(distroseries, status, archive, id); | 23:28 |
| wgrant | Ahh. | 23:28 |
| lifeless | is what we tried | 23:28 |
| wgrant | Interesting. | 23:28 |
| wgrant | That's better for this particular query, but worse for others, but mine worked fine on mawson. | 23:28 |
| wgrant | Can you tell why the planner is avoiding the index? | 23:29 |
| lifeless | Limit (cost=0.00..105.89 rows=31 width=36) (actual time=0.106..0.108 rows=1 loops=1) | 23:29 |
| lifeless | -> Index Scan Backward using packageupload__distroseries__status__archive__idx on packageupload (cost=0.00..5365.99 rows=1571 width=36) (actual time=0.104..0.106 rows=1 loops=1) | 23:29 |
| lifeless | Index Cond: ((distroseries = 104) AND (status = 0)) | 23:29 |
| lifeless | Filter: (archive = ANY ('{1,534}'::integer[])) | 23:29 |
| lifeless | Total runtime: 0.159 ms | 23:29 |
| lifeless | wgrant: what are the other queries? theres no reason for use to ues the same query for different cases | 23:30 |
| lifeless | bah, you know what I mean | 23:30 |
| wgrant | lifeless: Everything except that page is driven by archive, not distroseries. So having archive first is going to be more generally useful. | 23:31 |
| lifeless | wgrant: anyhow, *why* do we need id to sort before archive *on this page* | 23:31 |
| wgrant | lifeless: Because it's meant to be a chronological ordering, not have every partner upload ever first. | 23:32 |
| wgrant | Perhaps if primary was first. | 23:32 |
| wgrant | But definitely not partner. | 23:32 |
| lifeless | wgrant: this is for processing NEW right? | 23:32 |
| wgrant | lifeless: Not just NEW, but yes. | 23:33 |
| wgrant | lifeless: The other statuses get looked at to see what has happened to various packages. | 23:34 |
| wgrant | And having to scroll through an indeterminate number of pages of partner to get to the latest uploads is not going to make people happy. | 23:34 |
| lifeless | https://bugs.launchpad.net/launchpad/+bug/276950/comments/23 | 23:34 |
| _mup_ | Bug #276950: DistroSeries:+queue Timeout accepting many packages queue page <lp-soyuz> <queue-page> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/276950 > | 23:34 |
| wgrant | Both because it's stupid, and because it's partner. | 23:34 |
| wgrant | lifeless: What if you try another series? | 23:35 |
| wgrant | The planner is being really stupid here. | 23:35 |
| lifeless | wgrant: this is ubuntu | 23:36 |
| lifeless | no ? | 23:36 |
| wgrant | lifeless: Ubuntu and Canonical Partner. | 23:36 |
| lifeless | yes | 23:36 |
| lifeless | wgrant: so, I propose we take a different approach to fixing this | 23:36 |
| lifeless | wgrant: a) define the scope | 23:37 |
| lifeless | b) solve that scaope | 23:37 |
| lifeless | c) wait for others to have issues | 23:37 |
| lifeless | theres no a-priori requirement to have the same query generated by python for different use cases. | 23:37 |
| wgrant | The same query is fine. | 23:38 |
| wgrant | PostgreSQL's planner is not. | 23:38 |
| lifeless | folk shouldn't be scrolling through pages and pages to get to things | 23:39 |
| lifeless | thats nuts anyway | 23:39 |
| lifeless | so I really don't think we should care about status not in (0,1) | 23:39 |
| lifeless | and for status in (0,1) its a work queue thats meant to be driven to zero; it shouldn't normally matter if we group on archive or not | 23:40 |
| wgrant | These postgres workarounds are piling up. | 23:40 |
| wgrant | But OK. | 23:40 |
| lifeless | we can do a partial index - (date_created desc, archive, distroseries) where status in (0,1) | 23:41 |
| lifeless | that models the work queue case accurately. | 23:41 |
| lifeless | which is *always* going to be lopsided | 23:41 |
| lifeless | the non-queue case is 2.7MILLION rows | 23:41 |
| wgrant | lifeless: And the indexes handle that trivially, when they are properly used. | 23:42 |
| wgrant | But we cannot make them be properly used. | 23:42 |
| lifeless | wgrant: storing a work queue in a historical table is improper use | 23:42 |
| wgrant | Because postgres doesn't let us override its bad judgement. | 23:42 |
| lifeless | wgrant: thats why postgresql is having trouble | 23:42 |
| wgrant | lifeless: It depends on your definition of "proper", but probably. | 23:42 |
| lifeless | proper = will work well for the DB stack we're using | 23:43 |
| wgrant | I would s/proper/hackish/ | 23:43 |
| lifeless | wgrant: working against the stack will be hard | 23:44 |
| lifeless | wgrant: its not adroit :P | 23:44 |
| wgrant | Sure. | 23:44 |
| wgrant | But it's still a really bad hack. | 23:44 |
| wgrant | We probably have no choice. | 23:44 |
| lifeless | wgrant: what makes it that ? | 23:44 |
| wgrant | But that doesn't make it good. | 23:44 |
| lifeless | wgrant: seriously, we're not using bdb | 23:44 |
| wgrant | lifeless: We are changing data models and rewording queries to convince the postgres planner to do exactly what we want it to do. | 23:45 |
| wgrant | When we know exactly what we want it to do, but we can't tell it that. | 23:45 |
| lifeless | wgrant: you're talking about query hinting ? | 23:45 |
| lifeless | wgrant: how would you describe what we want the planner to do? | 23:46 |
| lifeless | wgrant: (in english) - because looking at the indices *and the query constraints* I think its being pretty sane | 23:46 |
| lifeless | specifically, its looking for a small number of rows near the end of the table by walking backwards. | 23:47 |
| lifeless | its been told: | 23:47 |
| lifeless | - we don't want every row (limit 31) and we want the beginning of the sequence (offset 0) | 23:47 |
| lifeless | so its a very smart choice. | 23:47 |
| wgrant | lifeless: It's avoiding using an index which is perfect for that query. | 23:48 |
| wgrant | We know that. | 23:48 |
| wgrant | But the skewed data prevents it from knowing that. | 23:48 |
| lifeless | packageupload__distroseries__status__idx isn't perfect for the query | 23:48 |
| wgrant | With archive and id it is. | 23:48 |
| lifeless | wgrant: results of hte partial on the bug | 23:50 |
| wgrant | Thanks. | 23:50 |
| lifeless | wgrant: the index isn't perfect - archive 1 + 534 - 1M rows | 23:51 |
| wgrant | Is comment #24 corect? | 23:52 |
| wgrant | How is the index condition distroseries, when date_created is first in the index? | 23:52 |
| lifeless | its scanning the index | 23:53 |
| lifeless | it can't select at the root | 23:53 |
| lifeless | but because its only looking at status 0,1 its very cheap | 23:53 |
| wgrant | Ah, true. | 23:54 |
| lifeless | it can satisfy the distroseries rule from the index | 23:54 |
| lifeless | before looking at table row | 23:54 |
| wgrant | We will probably need to revisit this in a year or so. | 23:54 |
| wgrant | Once we have a derivative distro or two. | 23:54 |
| lifeless | Index cond -- index tells us, filter -- table row is used. | 23:54 |
| lifeless | and - win | 23:54 |
| lifeless | we can make the current query use it | 23:54 |
| wgrant | How fast? | 23:55 |
| lifeless | 7ms | 23:55 |
| wgrant | Not bad. | 23:55 |
| lifeless | I can live with it | 23:55 |
| wgrant | It still leaves accepted/rejected/done timing out often, but I guess that is less of a user-affecting issue. | 23:55 |
| lifeless | wgrant: that use case needs to be revisted anyway | 23:57 |
| lifeless | wgrant: it should be a search etc, not a freaking pagination | 23:57 |
| lifeless | wgrant: showing 1M rows of done in a pagination view is very hard to do at all, let alone well | 23:58 |
| wgrant | Indeed. | 23:58 |
| lifeless | wgrant: I'm going to prep a db patch to add the index, and get it applied live | 23:59 |
| wgrant | lifeless: Thanks. | 23:59 |
| lifeless | I think jam has halted(), we should do loggerhead ourselves | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!