| wallyworld_ | wgrant: i ran into some issues with by branch but finally got them sorted. it would be great if you could review it | 01:28 |
|---|---|---|
| wallyworld_ | https://code.launchpad.net/~wallyworld/launchpad/create-aag-privacy-transitions2-1009364/+merge/110706 | 01:28 |
| wgrant | wallyworld_: Looking. | 01:41 |
| wallyworld_ | thanks | 01:41 |
| wgrant | wallyworld_: That bugtasksearch change is worrisome. | 01:43 |
| wgrant | wallyworld_: eg. it breaks TextualBugTaskSearchListingView | 01:44 |
| wallyworld_ | i didn't run all the tests | 01:44 |
| wallyworld_ | we can leave it as it was but it will continue to return duplicates | 01:45 |
| wgrant | Normal bug searches return duplicates too. | 01:45 |
| wallyworld_ | which is unfortunate | 01:45 |
| lifeless | how so ? | 01:45 |
| wgrant | It just happens that this method only returns the bug ID, so they're more obvious. | 01:45 |
| wallyworld_ | lifeless: since when would it be expected a search result should be ok to return dups? | 01:46 |
| wgrant | They're not strictly duplicates. | 01:46 |
| wallyworld_ | they are if they are ids | 01:46 |
| wgrant | In that particular format they are. | 01:46 |
| wgrant | I'm not sure it's useful to suppress them. | 01:47 |
| wallyworld_ | i can use a set instead of a list when i consume them | 01:47 |
| wgrant | And the way you've done it there breaks textual searches and kills performance. | 01:47 |
| wallyworld_ | so no problem, i'll revert and work around it | 01:48 |
| wgrant | I agree the method's current result is less than optimal. | 01:48 |
| wgrant | But it's all-round easier and not too much uglier to work around it using set() | 01:48 |
| wallyworld_ | apart from that, ok? | 01:48 |
| wgrant | + if information_type in PRIVATE_INFORMATION_TYPES: | 01:49 |
| wgrant | shouldn't that check that it's coming from something public? | 01:49 |
| wallyworld_ | probably | 01:49 |
| wallyworld_ | but maybe not | 01:50 |
| wallyworld_ | since i person may have had access before but not now | 01:50 |
| wallyworld_ | due to the new info type | 01:50 |
| wgrant | Ah, true. | 01:50 |
| wallyworld_ | eg they had an APG | 01:50 |
| wgrant | Yep, you are completely correct. | 01:50 |
| wgrant | But a comment to that effect might be handy. | 01:50 |
| wallyworld_ | ok, will d. this stuff can hurt one's brain | 01:51 |
| wgrant | Yup | 01:51 |
| StevenK | wgrant: Can? Does. | 01:51 |
| StevenK | Er, wallyworld_, even. | 01:51 |
| wallyworld_ | yep | 01:51 |
| wgrant | wallyworld_: findPeopleWithoutAccess doesn't seem to have a good reason to be on APGF, and it doesn't seem to check policy grants. | 01:55 |
| wgrant | APGF is only flattened in one direction, not the other. | 01:56 |
| wgrant | A grant for an artifact shows up in APGF linked to all the artifact's policies. | 01:56 |
| wgrant | But a grant for a policy doesn't show up linked to all of the artifacts, because that can be hundreds of thousands of rows. | 01:56 |
| wgrant | And that set is much quicker to query the other way. | 01:56 |
| wallyworld_ | wgrant: it's there because it queries the aggf table, hence is with the other methods which do such queries | 01:57 |
| wgrant | wallyworld_: It queries the subset of APGF that is AAG. | 01:57 |
| wgrant | APGF is good for getting all the grants related to a policy. | 01:58 |
| wgrant | It *doesn't* work for getting all the grants related to an artifact. | 01:58 |
| wallyworld_ | hmm. i will look at reworking it | 01:59 |
| wgrant | I'm pretty sure that CTE also just overcomplicates things. | 01:59 |
| wallyworld_ | it makes the core query a bit simpler to grok | 02:00 |
| wgrant | It should be a pretty simple query through TP, AAG, APA and APG | 02:00 |
| wallyworld_ | which you are saying you would prefer in the service? | 02:00 |
| lifeless | wallyworld_: so its not that duplicates in that method are desired, its that; a) forcing distinct in the DB forces a sort and merge, and sometimes we don't want that; secondly bug search is a horrid engine today, and keeping it sane is tricky | 02:01 |
| wgrant | I think it's probably best in the service. | 02:01 |
| wgrant | Given it's sort of over-arching and doesn't fit in any of the others.' | 02:01 |
| wallyworld_ | lifeless: yeah, understood, i was just responding to my assumption that you were questioning my view on whether duplicates in search results were good or bad | 02:01 |
| lifeless | ah | 02:02 |
| lifeless | so, on general searches, we have a discontinuity in the UI | 02:02 |
| lifeless | we show tasks | 02:02 |
| lifeless | but claim to show bugs | 02:02 |
| wgrant | Well | 02:02 |
| wallyworld_ | yeah | 02:02 |
| wgrant | Tasks don't exist. | 02:02 |
| lifeless | this confuses folk :) and is where the 'duplicates' come from | 02:02 |
| wgrant | The UI deliberately never mentions tasks. | 02:02 |
| wallyworld_ | lifeless: sure, but in this case, i invoke the api that gives ids, and those are indeed duplicated | 02:03 |
| lifeless | wgrant: abstractions leak; this leaks. | 02:03 |
| * StevenK stabs Django | 02:03 | |
| wgrant | lifeless: Of course. | 02:03 |
| wgrant | wallyworld_: Apart from that method being wrong, and the bug search thing, this looks good, thanks. | 02:03 |
| wallyworld_ | wgrant: cool, already fixed the search method, will move the other code, thanks for looking | 02:04 |
| wgrant | We need a couple of nice big cleanup pass through all this once the legacy stuff is removed. | 02:04 |
| wgrant | Great. | 02:04 |
| StevenK | wgrant: http://pastebin.ubuntu.com/1046567/ | 02:11 |
| StevenK | lifeless: I can now import auditor.manage and auditor.settings in bin/auditor-manage, but it now can't find the module auditlog :-( | 02:17 |
| lifeless | thats auditor.auditlog, right ? | 02:22 |
| wgrant | StevenK: Hm, you didn't check security.py-cleanliness before you landed? | 02:25 |
| StevenK | lifeless: Yeah, but loading that in bin/auditor-manage doesn't help. | 02:34 |
| StevenK | wgrant: Obviously not. :-( | 02:34 |
| wgrant | StevenK: Anyway, should be fine. Land a fix now, but the default EXECUTE should be sufficient to make it all work for tonight. | 02:34 |
| StevenK | wgrant: Where should the three of them go? launchpad_main ? | 02:35 |
| wgrant | (in postgres, functions default to granting EXECUTE to PUBLIC) | 02:35 |
| wgrant | StevenK: public, with the ret. | 02:35 |
| wgrant | st | 02:35 |
| wgrant | rest | 02:35 |
| wgrant | Pretty much every function should be in public. | 02:35 |
| StevenK | wgrant: Right, land to db-devel? | 02:35 |
| wgrant | StevenK: Indeed. | 02:36 |
| wgrant | As long as nothing further has landed there after your patch. | 02:36 |
| wgrant | (other than merges from stable) | 02:36 |
| * StevenK re-checks the deployment report. | 02:36 | |
| StevenK | Looking good on that front. | 02:37 |
| StevenK | wgrant: Some of the functions are listed with no rights. How do I tell if the new functions should be no rights? | 02:42 |
| wgrant | StevenK: The ones that don't need any rights should have no rights :) | 02:44 |
| wgrant | Things that are only called as helpers from SECURITY DEFINER functions don't need to be executable by normal users. | 02:44 |
| StevenK | wgrant: http://pastebin.ubuntu.com/1046591/ | 02:45 |
| wgrant | It's not a problem for all of these methods to be publicly executable. | 02:45 |
| wgrant | But they don't all need to be. | 02:45 |
| wgrant | StevenK: That should break. | 02:46 |
| wgrant | accessartifact_denorm_to_artifacts is called by accessartifact_maintain_denorm_to_artifacts_trig | 02:46 |
| wgrant | Which is not SECURITY DEFINER. | 02:46 |
| * StevenK adds EXECUTE rights to it. | 02:47 | |
| wgrant | branch_denorm_access too | 02:47 |
| wgrant | build_access_cache can be EXECUTE if you want, but I don't believe it's necessary. | 02:47 |
| StevenK | wgrant: Hah, maintain_transitively_private() isn't in security.cfg. | 02:48 |
| wgrant | StevenK: It's a trigger function. | 02:51 |
| StevenK | wgrant: Those security.cfg changes don't cause any tests in test_branch_access_policy_triggers, test_bugtaskflat_triggers and test_bug_mirror_access_triggers to fail. | 02:55 |
| wgrant | That's a start. | 02:55 |
| StevenK | wgrant: Shall I push it up? | 02:56 |
| wgrant | Might as well. | 02:56 |
| wgrant | Throw it off to ec2. | 02:56 |
| StevenK | Oh, stub needs to sticky beak it? | 02:56 |
| lifeless | nup | 02:56 |
| wgrant | Not for security.cfg, no | 02:56 |
| StevenK | wgrant: https://code.launchpad.net/~stevenk/launchpad/db-branch-nap-security/+merge/110709 and it's currently in the middle of setting up ec2 test | 03:03 |
| wgrant | StevenK: Thanks. | 03:09 |
| StevenK | Except it's testing against devel. Fail. | 03:14 |
| StevenK | ec2 kill needs to die early if you don't specify an instance id rather than failing with an obtuse traceback. | 03:15 |
| wgrant | StevenK: Probably doesn't matter, if your branch is from db-devel in the first place. | 03:16 |
| StevenK | Mmmmmm | 03:17 |
| StevenK | Too late, was the cry | 03:17 |
| wallyworld_ | wgrant: i've pushed the changes to my branch | 03:24 |
| wgrant | wallyworld_: Looking | 03:24 |
| wallyworld_ | thanks | 03:24 |
| wgrant | wallyworld_: The branch got cursed again? | 03:25 |
| wallyworld_ | yep | 03:25 |
| wgrant | Excellent. | 03:25 |
| wgrant | Maybe we can work out what it's hanging on. | 03:25 |
| wgrant | webops: Hi | 03:25 |
| spm | yo | 03:25 |
| wgrant | spm: The branch scanner hates some branches sometimes, hanging for more than 5 minutes before timing out. I'd like to trigger a hang and then get pg_stat_activity checked to see what it's doing. | 03:26 |
| spm | can we do that in staging? | 03:26 |
| wgrant | We've never reproduced it there. | 03:27 |
| wgrant | Or on dev. | 03:27 |
| spm | have we ever tried? :-) | 03:27 |
| wgrant | Yup | 03:27 |
| spm | just checking, your wording could have been taken as very cautiously spaken | 03:27 |
| wgrant | Heh | 03:27 |
| wgrant | True. | 03:27 |
| spm | so we know which branches do this on a regular basis? it's not the on disk bzr side perhaps? | 03:28 |
| wgrant | Nothing does it on a regular basis, AFAICT. It's normally a new branch that gets permanently cursed. | 03:29 |
| wgrant | Pushing it up under another name works. | 03:29 |
| spm | huh, weird. | 03:29 |
| wgrant | Precisely. | 03:29 |
| spm | how do you propose to trigger? and do we know which DB server(s) we need stats from? is it worth doing a * * * * * pg_stat_dump > logfile? | 03:29 |
| wgrant | spm: branchscanner user on wildcherry | 03:30 |
| wgrant | We trigger by wallyworld forcing a scan on that branch. | 03:30 |
| wgrant | With a push | 03:30 |
| spm | is wallyworld_ planning on promising cake to go with this debug? cause, you know, cake. | 03:30 |
| wallyworld_ | wgrant: you want me to do that now? | 03:30 |
| wallyworld_ | spm: i have no cake - the dog ate it | 03:31 |
| spm | so I hear | 03:31 |
| spm | wgrant: select * from pg_stat_activity where usename='branchscanner'; or do you want the full thing, jic? | 03:32 |
| wgrant | spm: That'll do | 03:32 |
| wgrant | wallyworld_: Please. | 03:32 |
| wgrant | I have my rsynctail running to observe the hang. | 03:33 |
| wallyworld_ | wgrant: just pushed -r-2 and then -r-1 | 03:33 |
| wgrant | It be scanning. | 03:34 |
| wgrant | spm: Can you check pg_stat_activity now? | 03:35 |
| spm | been grabbing heaps the past min or so | 03:35 |
| wgrant | Great. | 03:35 |
| wgrant | Been going for a minute now, which is itself a good sign that it's hung. | 03:35 |
| wgrant | Should normally take about 50s. | 03:35 |
| spm | probably should have while looped, but anyway | 03:35 |
| wgrant | yay, it has hung. | 03:36 |
| spm | appears stuck in a SELECT | 03:36 |
| wgrant | First time we've caught it in the act. | 03:36 |
| wgrant | What is the SELECT? | 03:36 |
| spm | it's a secret, that will be exposed on production of cake | 03:36 |
| wgrant | Sneaky. | 03:37 |
| spm | indeed. a cunning plan even | 03:37 |
| spm | wgrant: https://pastebin.canonical.com/68304/ | 03:37 |
| spm | still at the same place nearly a minute later too | 03:38 |
| wgrant | Aha | 03:38 |
| wgrant | Thanks. | 03:38 |
| wgrant | Should time out in 20s or so | 03:39 |
| lifeless | so, code review + http://okfnlabs.org/annotator/demo/ | 03:39 |
| spm | still holding atm | 03:39 |
| wgrant | spm: It's done, btw. | 03:42 |
| wgrant | timed out, as expected. | 03:42 |
| spm | and yes, cleared here as well | 03:42 |
| wgrant | spm: any more interesting queries? | 03:42 |
| spm | not for branchsscanner | 03:42 |
| wgrant | I mean from before the SELECT of Doom. | 03:42 |
| spm | I can paste you a rather "long" session history, if you're interested? | 03:43 |
| wgrant | That might be handy, thanks. | 03:43 |
| spm | <IDLE> in transaction <== a fair bit | 03:43 |
| wgrant | Better than having to do this again. | 03:43 |
| wgrant | Yeah | 03:43 |
| spm | wgrant: https://pastebin.canonical.com/68305/ | 03:44 |
| wgrant | spm: Thanks! | 03:45 |
| wgrant | It has traditionally been suspected that bzr slowness was the issue here, but this proves otherwise :) | 03:47 |
| wgrant | Now, it doesn't actually tell us how it's being so slow, but at least it's something. | 03:48 |
| spm | wgrant: I'd like to point out that your email address is in that query; QED, it's all your fault. <== advanced sysadmin debug. | 03:48 |
| wgrant | That's good solid logic you have there :) | 03:48 |
| spm | I'm glad you approve | 03:48 |
| wgrant | Hmmm | 04:05 |
| wgrant | So the branch has a full set of BranchRevisions, but no last_scanned_id | 04:05 |
| wgrant | This is causing subsequent runs to try to clear the entire history. | 04:06 |
| wgrant | But it doesn't explain what happened during the initial failure. | 04:06 |
| wgrant | wallyworld_: How soon after pushing the branch did you create the MP? | 04:08 |
| wallyworld_ | wgrant: almost straight away | 04:09 |
| wgrant | A saw a WIP MP pretty soon after the push | 04:09 |
| wgrant | Looks like that is how to repro it. | 04:09 |
| wgrant | I wonder if we're deadlocked with the MPJ runner. | 04:10 |
| wallyworld_ | plausible | 04:10 |
| wgrant | 2 minutes so far... | 04:10 |
| wgrant | That means we have two bugs. | 04:10 |
| wgrant | Fail | 04:10 |
| wgrant | Took 2.5 minutes, but it succeeded | 04:11 |
| wallyworld_ | branch revision has a lot to answer for | 04:12 |
| * wallyworld_ -> school and back | 04:12 | |
| wgrant | wallyworld_: Why not do the grants after _reconcileAccess, so you can use APAs rather than having getPeopleWithoutAccess duplicate the pillar determination logic? | 04:27 |
| StevenK | wallyworld_: So, QA? :-) | 04:40 |
| StevenK | wgrant: Hmm, so you think MPJ and the scanner lock? | 04:40 |
| StevenK | Plausible, indeed. | 04:40 |
| wgrant | Discounted in this case, it seems. | 04:42 |
| wgrant | The first logged MPJ was 12 minutes after the scan timed out. | 04:42 |
| wgrant | wallyworld_: https://bugs.launchpad.net/launchpad/+bug/808930/comments/20 is the result of the debugging, btw. | 05:28 |
| _mup_ | Bug #808930: Timeout running branch scanner job <escalated> <linaro> <oops> <Launchpad itself:In Progress by abentley> < https://launchpad.net/bugs/808930 > | 05:28 |
| wallyworld_ | wgrant: so we really want to delete BranchRevision :-) | 05:43 |
| wgrant | wallyworld_: But it's my friend :( | 05:45 |
| wallyworld_ | wgrant: i'm not sure i follow your review suggestion above | 05:48 |
| wallyworld_ | i do call ensureAccessGrants after reconcileAccess | 05:48 |
| wgrant | wallyworld_: Right, then you don't need to manually determine the pillars for bugs and branches. | 05:49 |
| wgrant | You can just use the APAs | 05:49 |
| wallyworld_ | wgrant: so, i use IAccessPolicyArtifactSource.find() to fill out the policies_to_check array? | 05:52 |
| wgrant | wallyworld_: AccessPolicyArtifact.artifact = abstract_artifact.id AND AccessPolicyGrant.policy = AccessPolicyArtifact.policy AND AccessPolicyGrant.grantee = TeamParticipation.team | 05:53 |
| wgrant | Python never needs to see the policies. | 05:54 |
| wgrant | They're purely used by the join from AccessArtifact to AccessPolicyGrant. | 05:54 |
| wallyworld_ | ah ok. | 05:54 |
| lifeless | gary_poster: btw, trunk testrepository has a --concurrency option for you | 05:55 |
| wgrant | wallyworld_: Oh, also, that whole thing is pretty strange. Your top-level query has "Person.id IN person_ids AND Person.id NOT IN policy_grantees AND Person.id NOT IN artifact_grantees", but then policy_grantees and artifact_grantees also filter on person_ids. | 05:56 |
| wallyworld_ | wgrant: i was attempting to limit the size of the in lists | 05:57 |
| wallyworld_ | the top level In(Person.id, person_ids) is because we only want people withotu access from those that are specified | 05:58 |
| wgrant | wallyworld_: They're not lists, they're subquery expressions :) | 05:59 |
| wgrant | It optimises through them. | 05:59 |
| wallyworld_ | sure, but the subsquery still returns results | 05:59 |
| wgrant | Not really, no. | 05:59 |
| wallyworld_ | internally | 06:00 |
| wgrant | Again, not really :) | 06:00 |
| wgrant | Theoretically perhaps. | 06:00 |
| wallyworld_ | so if i limit the size of the subquery, it's more efficient | 06:00 |
| wallyworld_ | it is with oracle anyway | 06:00 |
| wgrant | Not necessarily. | 06:00 |
| wgrant | Also not necessarily. | 06:00 |
| wgrant | It depends on how you're limiting the size. | 06:00 |
| wgrant | So | 06:00 |
| wgrant | I'd pull the TP join out. | 06:01 |
| wgrant | There's no reason to have it all the way down there. | 06:01 |
| wgrant | If I were postgres, I'd plan that as a nested loop, and the person_filter inside the subqueries would have no effect whatsoever. | 06:03 |
| wallyworld_ | ok, i'll take a look. maybe a run on dogfood to check ite performance is needed | 06:03 |
| wgrant | Any reasonably query planner can see that. | 06:03 |
| stub | The planner is smarter than you, except when it isn't. | 06:08 |
| wgrant | In this case it should be :) | 06:08 |
| wallyworld_ | wgrant: this should be ok i think https://pastebin.canonical.com/68312/ | 06:10 |
| wallyworld_ | except for flat maybe | 06:10 |
| wallyworld_ | yes, flat is gone | 06:11 |
| wallyworld_ | https://pastebin.canonical.com/68313/ | 06:13 |
| wgrant | wallyworld_: If I were writing it, I'd phrase it as the set difference between the requested people and the result of https://pastebin.canonical.com/68315/ | 06:27 |
| wgrant | But your new version looks correct. | 06:27 |
| wgrant | (although the distincts on the subqueries are pointless) | 06:27 |
| wallyworld_ | wgrant: looks like your version returns the oppoiste of what is wanted? | 06:28 |
| wgrant | wallyworld_: Right, positive queries are much easier to write directly. | 06:30 |
| wgrant | Anyway, yours is OK if you drop the distinct=Trues | 06:31 |
| wgrant | Mine is much faster, but we shouldn't have performance issues here anyway. | 06:31 |
| wgrant | Since the dataset is small. | 06:31 |
| lifeless | wgrant: distinct on subquery is a planner hint | 06:33 |
| lifeless | wgrant: as is offset 0; | 06:33 |
| lifeless | s/hint/sledgehammer/ | 06:33 |
| wallyworld_ | wgrant: i've removed the distincts, i can rework to match your logic | 06:34 |
| wgrant | lifeless: Maybe in postgres 6.1 | 06:37 |
| wgrant | lifeless: But IN implies distinct on the subquery nowadays | 06:37 |
| wgrant | Plus we have no reason to use planner deception techniques here. | 06:37 |
| wgrant | You should use them once it's shown that you need them; not before :) | 06:38 |
| wgrant | wallyworld_: The rework's not critical, but I wonder if it makes more sense as a getPeopleWithAccess anyway | 06:38 |
| wgrant | wallyworld_: eg. for determining who gets notified. | 06:38 |
| wgrant | (for later structural subscription enablement) | 06:39 |
| wallyworld_ | wgrant: we can add a method for that, but i'd rather use the db for now to find people without access | 06:39 |
| wgrant | You're probably better off having a single method and doing integral set difference in Python. | 06:40 |
| wallyworld_ | i used distinct onthe sub queries from prior experience, but whio know what postgres dowesa | 06:40 |
| wallyworld_ | wgrant: i was trying to avoid anyting in python | 06:41 |
| wgrant | It's almost always prettier to do set difference in Python than it is to describe non-trivial negative assertions in SQL :) | 06:41 |
| wgrant | Perhaps. | 06:41 |
| wgrant | StevenK: Going to qa-ok your db-stable rev? | 06:41 |
| StevenK | I got distracted by auditor | 06:44 |
| StevenK | wgrant: db-branch-nap-security => db-devel [OK] (up for 3:29:40) i-b2f88acb | 06:45 |
| wgrant | That's encouraging. | 06:45 |
| wallyworld_ | wgrant: are you ok to +1 the mp and i'll land after i've had a look at rejigging the query to you your logic? i'd still like to keep everything in the db for now | 06:49 |
| wgrant | Just +1ing now, yep. | 06:49 |
| wallyworld_ | and we can pull out common query expr for notofications later if needed | 06:49 |
| wallyworld_ | thanks | 06:49 |
| wgrant | If loggerhead wakes up | 06:49 |
| wgrant | There we go | 06:51 |
| wgrant | Thanks. | 06:51 |
| wallyworld_ | wgrant: thanks. btw, the bloody bug subscription removal job still oopes on qas :-( | 06:54 |
| wgrant | wallyworld_: No idea why? | 06:54 |
| wallyworld_ | error reading 'infoformation types' from job metadata | 06:54 |
| wgrant | wut | 06:54 |
| wgrant | examining log | 06:54 |
| wallyworld_ | yeah, haven't looked too much nto it | 06:54 |
| wallyworld_ | the should should only be able to be constructed such that metadata is written with info type key | 06:55 |
| wgrant | Oh | 06:55 |
| wgrant | What if it's old data? | 06:55 |
| wgrant | From before the jobs were merged. | 06:55 |
| wallyworld_ | ah, that is it i think | 06:55 |
| wgrant | It's certainly what it looks like. | 06:56 |
| wallyworld_ | so, i'll do a branch to make the code robnust | 06:56 |
| wgrant | Mmm | 06:56 |
| wgrant | No | 06:56 |
| wgrant | It shouldn't be robust against information_types being missing. | 06:56 |
| wgrant | Oh, if it's in getOperationDescription, hm, maybe. | 06:56 |
| wallyworld_ | it's trivial to do though | 06:56 |
| wgrant | It is, yeah | 06:56 |
| wallyworld_ | missing = [] | 06:56 |
| wallyworld_ | so close to being able to turn all this shit on | 06:57 |
| wgrant | Heh | 06:57 |
| wgrant | Yeah | 06:57 |
| wallyworld_ | finally | 06:57 |
| wgrant | StevenK: fdt requested | 06:59 |
| StevenK | \o/ | 07:00 |
| StevenK | wgrant: What shall we do with this security.cfg branch, then? | 07:00 |
| wgrant | StevenK: It'll be landable on db-devel before this is deployed. | 07:00 |
| wgrant | Land it on db-devel before this is deployed. | 07:00 |
| wgrant | We can then merge db-devel instead of the relevant rev of db-stable. | 07:01 |
| wgrant | Since nothing further of consequence has landed on db-devel to stop us from doing that. | 07:01 |
| wgrant | Keeps the MP happy. | 07:01 |
| StevenK | wgrant: Sounds like a good plan. | 07:02 |
| StevenK | wgrant: db-devel r11688 | 07:43 |
| adeuring | good morning | 07:45 |
| wgrant | StevenK: Thanks. | 07:45 |
| === almaisan-away is now known as al-maisan | ||
| lifeless | wgrant: in 8.4 distinct made a different in subqueries, FWIW. Haven't tested in 9.1 yet. | 08:27 |
| czajkowski | jml: have to ask, what headset do you use and do you recommend it ? | 09:24 |
| jml | czajkowski: I use my Bose QC3 headphones with a mic cable. I've successfully used Logitech USB headsets in the past. | 09:24 |
| jml | czajkowski: ultimately, what matters is that it's well-tested and that it doesn't leak noise into the mic. | 09:25 |
| jml | perhaps it's inevitable when you have > N people, but it always seems as if someone is on a combination of hardware/software that they are only using for the first time that day. | 09:26 |
| jam | wgrant: I'm planning on re starting the fix and then copy translations for Q today. I was hoping to get more insight into how it failed on friday. In case it is more of a systemic issue. | 10:34 |
| jam | What process was it that you thought was adding data? (User filling out translations for P and that somehow ending up in Q?) | 10:34 |
| wgrant | jam: Translations are shared between series. | 10:35 |
| wgrant | So a translation in Precise can show up in Quantal. | 10:35 |
| wgrant | Or even a translation in an upstream project. | 10:35 |
| jam | wgrant: so I understand that they can be shared, and that is my understanding of why we are running a 'copy' script in the first place. But I'm trying to understand how/what decides to put a Q entry in when submitting a P entry. | 10:36 |
| wgrant | jam: The normal Translations model code in the webapp. | 10:36 |
| jam | wgrant: I'm poking through the code base, and I'm noticing a garbo script that touches the PO tables. Is that something we should be stopping along with the cron scripts? | 11:06 |
| jam | The script is ScrubPOFileTranslator | 11:07 |
| jam | anyone else able to answer how and when garbo runs and how likely it is to be inserting data into the db for a table we're trying to clean up? | 11:09 |
| wgrant | jam: That's in garbo-daily. | 11:10 |
| wgrant | It was introduced by jtv recently as part of this work. | 11:10 |
| wgrant | It maintains POFileTranslator, both adding and deleting | 11:10 |
| jam | wgrant: right, it was something he wanted to move into a refresh-the-db stuff so that it doesn't block the copy stuff | 11:10 |
| jam | but I don't know if we need to deactivate it, etc. | 11:11 |
| wgrant | 5 23 * * * $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/garbo-daily.py --abort-script=72000 -q --log-file=INFO:/srv/launchpad.net/production-logs/garbo-daily.log | 11:11 |
| wgrant | It died with fastdowntime, so it is not a concern. | 11:11 |
| wgrant | And it would have been dead on Friday too. | 11:11 |
| jam | wgrant: died with fastdowntime? | 11:11 |
| jam | as in, garbo-daily isn't working correctly? | 11:12 |
| jam | right now | 11:12 |
| wgrant | jam: fastdowntime killed its DB connection, as it was meant to. | 11:12 |
| wgrant | It's working fine, but not running atm since we killed it 72 minutes ago | 11:12 |
| jam | ah, and so won't be running again until tomorrow/tonight at 23:05 | 11:12 |
| jam | UTC? | 11:12 |
| wgrant | Right. | 11:12 |
| czajkowski | jelmer: vila mgz could one of you look at https://answers.launchpad.net/launchpad/+question/200576 please. | 11:17 |
| jelmer | czajkowski: on it | 11:18 |
| czajkowski | jelmer: lovely thanks | 11:18 |
| czajkowski | am looking forward to reading that fo my reference | 11:18 |
| jam | wgrant: another small thing (hopefully), we were getting email spam while the cron jobs were stopped. Is that something we can supress since we know that we manually stopped them? | 11:19 |
| wgrant | jam: You'll need to ask ops to disable the relevant script-monitor cronjobs. | 11:20 |
| === matsubara is now known as matsubara-lunch | ||
| czajkowski | cjwatson: on the installer does it ask you which drive to install Ubuntu on ? | 11:21 |
| jamestunnicliffe | Hi, since I don't have commit access but I have an approved branch, could someone kick off the test + check in cycle on this please: https://code.launchpad.net/~dooferlad/launchpad/workitems-bugfix/+merge/110563 | 11:21 |
| jam | wgrant: so the table that was getting new data was POFileTranslator (IIRC). However, I see this in the db: | 11:28 |
| jam | https://pastebin.canonical.com/68246/ | 11:28 |
| jam | sorry bad paste | 11:28 |
| jam | http://paste.ubuntu.com/1047080/ | 11:28 |
| jam | so why is new data being inserted there if it is considered 5-year old legac | 11:28 |
| jam | legacy. | 11:28 |
| czajkowski | jamestunnicliffe: not sure who does that is it a reviewer | 11:29 |
| cjwatson | czajkowski: You should get to choose in the event that you have multiple drives, last I checked, yes | 11:29 |
| jam | maybe pofiletranslator is still new, but the others are not? | 11:29 |
| czajkowski | cjwatson: that's what I thought, but do kinda feel bad for https://answers.launchpad.net/ubuntu/+question/200739 | 11:29 |
| czajkowski | cjwatson: last time I just installed ubuntu and wiped the machine when I bought it. | 11:30 |
| jam | yeah, that looks right. As it adds a function that does pretty much the same thing, to update POFileTranslator, but doing so from different source tables. | 11:30 |
| wgrant | jam: Huh? | 11:30 |
| wgrant | jam: That's dropping two functions to work with old tables. | 11:30 |
| jam | wgrant: I was misreading a comment. It was saying a table was legacy. | 11:30 |
| wgrant | Right. | 11:30 |
| jam | I thought it was saying POFileTranslator | 11:31 |
| jam | was the legacy table | 11:31 |
| jam | but it was saying the other ones were | 11:31 |
| wgrant | Right, no :) | 11:31 |
| wgrant | jam: Anyway, I'd just try again | 11:32 |
| wgrant | See what happens. | 11:32 |
| jam | yeah, I'm still waiting on ops, so I figured I'd try to at least understand how things are working together. | 11:32 |
| wgrant | To be clear, Translations is by far my weakest point. | 11:33 |
| wgrant | I don't really know how it works. | 11:33 |
| wgrant | Only very vaguely. | 11:33 |
| jam | If a db table is getting updates while doing COPY that seems a good way for copy to break | 11:33 |
| jam | It may not be the specific problem we've been running into. | 11:33 |
| jam | But it was the problem we ran into on Friday. | 11:33 |
| jam | for the delete step | 11:33 |
| wgrant | Not really. | 11:33 |
| wgrant | That was just deleting some stuff which violated FK references. | 11:34 |
| wgrant | Unrelated to the COPY. | 11:34 |
| jam | wgrant: we got an insert into POFileTranslator *after* we deleted everything. | 11:34 |
| wgrant | Sure. | 11:34 |
| jam | Which isn't related to copy | 11:34 |
| jam | but it means something was happening concurrently | 11:34 |
| wgrant | 21:33:40 < jam> But it was the problem we ran into on Friday. | 11:34 |
| wgrant | Right, people still translate through the web UI | 11:34 |
| jam | wgrant: right, we didn't get into copy on Friday. | 11:34 |
| wgrant | That's the concurrency. | 11:34 |
| wgrant | Ah | 11:34 |
| jam | my concern is that copy has been failing in the last couple of attempts, | 11:34 |
| jam | And I was trying to understand where the moving parts are | 11:35 |
| jam | in case there was an obvious trip up point. | 11:35 |
| jam | I could see copy failing if it expected something to be empty | 11:35 |
| wgrant | Has the copy been reached since the big changes that jtv did? | 11:35 |
| jam | no | 11:35 |
| wgrant | I thought that was in the second script. | 11:35 |
| wgrant | Right. | 11:35 |
| wgrant | So, ignore that, it should be quick enough now hopefully. | 11:35 |
| wgrant | First step is to get the deletion working. | 11:35 |
| jam | well, he thought delete should be small minutes, and at 40min it failed because of concurrent updates. | 11:36 |
| wgrant | And only debug it if it's broken :) | 11:36 |
| jam | and he isn't here for me to chat with today. | 11:36 |
| jam | that was my original goal | 11:36 |
| wgrant | This run should be a little quicker. | 11:36 |
| wgrant | Since it's already done most of the work. | 11:36 |
| jam | it deleted only about 40k rows, from POFIle, and I don't have a feeling for how many there should be. | 11:37 |
| jam | is it possibel to get that info from staging? | 11:37 |
| jam | or are those tables not copied over | 11:37 |
| wgrant | Didn't it get all the way through the first three phases, then fail on the fourth? | 11:37 |
| wgrant | The entire database is copied over. | 11:37 |
| jam | wgrant: there are 7 'statements' it runs via batches. | 11:38 |
| jam | it got to 3 | 11:38 |
| jam | 'delete_pofile' | 11:38 |
| jam | and got through 40k rows of that one | 11:38 |
| jam | I personally don't have a feel for how much data is there. | 11:38 |
| wgrant | Let me see. | 11:38 |
| jam | wgrant: its my understanding that some devs have direct SQL access on staging. It would appear that you might be one of them :) | 11:39 |
| wgrant | No | 11:39 |
| wgrant | I have access to dogfood | 11:39 |
| jam | ah | 11:39 |
| wgrant | Which is less up to date | 11:39 |
| lifeless | jam: as a teamlead you should get ro access to stagng and qastaging | 11:39 |
| wgrant | and about a billion times slower | 11:39 |
| lifeless | jam: you may need to request that via RT | 11:39 |
| jam | lifeless: and somehow figure out how to use it :) | 11:39 |
| lifeless | jam: thats the easy part | 11:39 |
| lifeless | night all | 11:39 |
| wgrant | lifeless: Why can't mortals have it too? :( | 11:40 |
| jam | lifeless: night | 11:40 |
| jam | isn't there a specific rt address you are supposed to file for launchpad-ish issues? | 11:40 |
| jam | rather than just rt@ | 11:40 |
| wgrant | jam: There's about 100k | 11:41 |
| wgrant | jam: launchpad@rt.canonical.com | 11:41 |
| jam | wgrant: so about halfway through that one. and then however many for the other tables | 11:42 |
| wgrant | jam: Right. But that should be the only widely referenced one. | 11:42 |
| jam | translationtemplateitem, packagingjob, translationimportqueueentry_potemplate, potemplate | 11:42 |
| jam | sure | 11:42 |
| wgrant | As long as the POFiles go, the POTemplates should have no trouble leaving. | 11:42 |
| wgrant | And the others are fine. | 11:42 |
| jam | wgrant: do you think the 40 min was a db load thing? (Anything to indicate db load was particularly high/low on Fri afternoon?) | 11:44 |
| wgrant | jam: I thought it was expected to be 30±20min | 11:44 |
| wgrant | The copy afterwards should be <10min AIUI | 11:44 |
| jam | well, I believe jtv said "minutes" but to me that is <30min | 11:45 |
| jam | you could argue it is just <1hr | 11:45 |
| wgrant | Oh, I had them the wrong way around. | 11:46 |
| wgrant | The fix script has never been used before AIUI | 11:46 |
| wgrant | So i's unsurprising that we don't know how long it takes. | 11:46 |
| jam | I'm a bit surprised that DBLoopTuner says it can only delete 20rows in 2s. | 11:46 |
| jam | https://pastebin.canonical.com/68241/ | 11:46 |
| jam | (goal_seconds was 2.0) | 11:47 |
| jam | speaking of DB stuff, hey stub | 11:47 |
| wgrant | Well | 11:48 |
| stub | ...and his amazing bouncing 'net connection | 11:48 |
| wgrant | The queries probably aren't exactly well-optimised. | 11:48 |
| wgrant | There are some multi-table joins in the where clauses of those deletes. | 11:48 |
| wgrant | SOme of the FKs are also unindexed. | 11:49 |
| wgrant | eg. poexportrequest.pofil | 11:49 |
| wgrant | But that table should be small. | 11:49 |
| wgrant | However, the join is slow. | 11:50 |
| wgrant | I suspect that's why it takes so long. | 11:50 |
| wgrant | On DF it chooses a merge join. | 11:52 |
| wgrant | Which is entirely ridiculous. | 11:52 |
| wgrant | But it can't be doing that on prod; it would be even slower then. | 11:53 |
| === benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | Welcome our new intern: ivory | On call reviewer: benji | Firefighting: - | Critical bugs: 3.47*10^2 | ||
| gary_poster | I saw on the bugreport that you had added it. Thank you lifeless! | 12:04 |
| === matsubara-lunch is now known as matsubara | ||
| jml | gary_poster: hi | 12:36 |
| gary_poster | hey jml! I was just considering procrastinating from my other tasks by replying to your email. :-) | 12:37 |
| jml | gary_poster: out of curiosity, is there a hit-list of bugs that have to be fixed before we can all enter into 40 min test time nirvana? | 12:37 |
| * jml almost remembers when it was 40 minutes even without parallelization. I think it was 50m when I started. | 12:38 | |
| jml | gary_poster: it just strikes me that if ever I were to do some spontaneous Launchpad hacking, that would be the single most selfish thing I could do. | 12:38 |
| jml | (or lazy or whatever vice pundits are parading as a virtue these days) | 12:39 |
| * jml is also procrastinating | 12:40 | |
| gary_poster | jml, There is a paralleltest tag, but I use the kanban board for my daily view so I'm not sure how accurate it is. We are at a relatively small number of actual bugs. Of the ones on my board, bug 1013921 is a nice to have (should increase speed by about 5 minutes) and is up your alley; investigating the fact that bug 994752 didn't really give us the stability we needed is not yet cooked enough. The main thing we | 12:40 |
| gary_poster | are waiting on now is getting the machines ready | 12:40 |
| _mup_ | Bug #1013921: our zope.testing fork needs to emit subunit time immediately before test start and immediately before test completion <paralleltest> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1013921 > | 12:40 |
| _mup_ | Bug #994752: lxc-start-ephemeral's use of dhcp lease table is fragile <patch> <verification-done> <lxc (Ubuntu):Fix Released> <lxc (Ubuntu Precise):Fix Released by stgraber> <lxc (Ubuntu Quantal):Fix Released> < https://launchpad.net/bugs/994752 > | 12:40 |
| gary_poster | that is, purchasing the new two 24 core machines for the data center | 12:41 |
| jml | wow. | 12:41 |
| jml | it's such a pity about the fork. :( | 12:41 |
| jml | I'm sorry for my part in that. | 12:41 |
| gary_poster | I'm not sure you had much to do with it, if any. The big problem is that we never want to pay the cost for a full zope package upgrade | 12:42 |
| gary_poster | At least, that's my guess in retrospect... | 12:42 |
| jml | every time I think about it I think, "We should stop using zope.testing. That means we must stop using layers. OK, let's start with the librarian layer. Ugh, that has some problem that lifeless tells me that I always forget about." | 12:42 |
| jml | and then give up | 12:42 |
| gary_poster | heh | 12:42 |
| gary_poster | and then I think "oh well, if we ever get to SOA it will SOLVE THE WORLD!" | 12:43 |
| jml | well, I have an opportunistic todo for incrementally approaching that | 12:43 |
| jml | some of the ugly monkey patches to zope.testing are mine, that makes upgrade harder | 12:44 |
| jml | also I think I might have done one of the first local patches. once you start down that path it's very hard to get back to the main road. | 12:44 |
| gary_poster | it's true that it is hard. And yeah, once we got to p4, it seemed less like a temporary situation and more like a road. We're on...p13 now, thanks to us. :-/ | 12:45 |
| gary_poster | Some of which includes our hilarity such as | 12:46 |
| gary_poster | # p11 reverts p9. | 12:46 |
| gary_poster | # p12 reverts p11, restoring p9. | 12:46 |
| gary_poster | whee! :-) | 12:46 |
| gary_poster | I was directly involved in that, so I think I am allowed to giggle | 12:47 |
| jml | heh :) | 12:47 |
| jml | There's also a sense in which zope forked away from us too. | 12:48 |
| gary_poster | yeah | 12:48 |
| gary_poster | it dying doesn't help anything either | 12:48 |
| jml | I can just imagine someone rubbing their hands and thinking, "At last! Our plot to alienate the last of our users is complete!" | 12:48 |
| jml | And then doing a wicked opera laugh. | 12:48 |
| gary_poster | lol | 12:48 |
| jml | fwiw, I did this as a braindump of things to have in a new project: https://docs.google.com/a/canonical.com/document/d/1A8qTOYZd7p9dhjmlnnEKW46h38ydt9yNbmfgX3yhPGw/edit – it's not a tested checklist, and it's depressingly long & in need of automation. I just started lp:libdep-service, so I'll probably use that to test this | 12:51 |
| gary_poster | jml, I like that list--"one other core contributor" in particular as a good insight | 12:53 |
| * gary_poster looks up libdep-service | 12:53 | |
| gary_poster | ah cool | 12:54 |
| jml | it's nothing special, just another microservice. | 12:56 |
| === al-maisan is now known as almaisan-away | ||
| === Ursinha` is now known as Ursinha | ||
| czajkowski | cjwatson: can I assign you https://answers.launchpad.net/launchpad/+question/200735 or can you let me knowthe info that needs to go to that page please. | 13:53 |
| gary_poster | matsubara, hey. I'm going to reboot to see if my camera works again then, and then I'll be ready | 13:59 |
| matsubara | gary_poster, sure, I don't have a camera, so if you want to use phone only it's fine by me | 14:00 |
| gary_poster | matsubara, oh ok, cool | 14:00 |
| rick_h | ivory: https://plus.google.com/hangouts/_/f2e9cf4efd2664584bc55d299ce1ff8075141388?authuser=0&hl=en-US | 14:00 |
| gary_poster | we can be blue heads together then | 14:00 |
| matsubara | heh | 14:01 |
| matsubara | ok, let me create the hang out | 14:01 |
| matsubara | gary_poster, https://plus.google.com/hangouts/_/bbe5d4266ba176d0f201f8eed73db4ac6b50640a?authuser=0&hl=en | 14:03 |
| dobey | from second life to google hangouts… | 14:03 |
| cjwatson | czajkowski: Yeah, you can assign that to me | 14:04 |
| czajkowski | cjwatson: cheers | 14:06 |
| gary_poster | matsubara, http://ec2-23-20-214-51.compute-1.amazonaws.com:8010/waterfall | 14:12 |
| nigelb | wtf. gmail just marked all of lifeless' emails as spam. :/ | 14:24 |
| jml | heh heh. | 14:27 |
| jam | dpm: the copy translations scripts has run, need to verify the results now | 14:29 |
| dpm | jam, cool :) | 14:29 |
| nigelb | jml: I've been wondering why lifeless hasn't been sending emails lately, heh. | 14:30 |
| cjwatson | czajkowski: done | 14:48 |
| czajkowski | cjwatson: oh if they were all only that simple today | 14:49 |
| cjwatson | czajkowski: Simple for you, anyway ;-) | 14:52 |
| czajkowski | cjwatson: I'm having a feel sorry for the users day today | 14:52 |
| czajkowski | issues with Ubuntu is getting logged in lp | 14:52 |
| czajkowski | I am intrigued how they get as far as creating a LP ac, filing a bug or a question, ticking Ubutu -> LP and not just leaving it as Ubuntu | 14:53 |
| jam | dpm: I see https://translations.launchpad.net/ubuntu/quantal is available, I won't have the time today to verify anything, but I'll look into that tomorrow. | 14:56 |
| dpm | jam, thanks. I'm a bit busy today too, but I'll look at it tomorrow too. | 14:58 |
| jml | cjwatson: https://code.launchpad.net/~jml/lazr.restfulclient/disable-ssl-cert-verification/+merge/110503 ; https://code.launchpad.net/~jml/launchpadlib/ssl-creds/+merge/110848 | 16:06 |
| cjwatson | jml: I *think* those are all the sites I found myself having to modify, yes. LGTM | 16:10 |
| jml | cjwatson: I managed a successful API call to dev with those. | 16:10 |
| jml | cjwatson: thanks. | 16:10 |
| cjwatson | (But I'm not an LP reviewer) | 16:10 |
| jml | benji: https://code.launchpad.net/~jml/lazr.restfulclient/disable-ssl-cert-verification/+merge/110503 ; https://code.launchpad.net/~jml/launchpadlib/ssl-creds/+merge/110848 | 16:11 |
| cjwatson | IIRC it's worth checking that it also works the second time round, with cached credentials. | 16:11 |
| jml | cjwatson: ah, thanks. | 16:15 |
| jml | all good. | 16:15 |
| === salgado is now known as salgado-lunch | ||
| jml | benji: ta | 16:16 |
| benji | jml: np | 16:17 |
| cjwatson | wgrant: For PCJ unembargo support, I'm taking the approach of pushing the update_files_privacy work down to _do_direct_copy "if not archive.private and has_restricted_files(source)", and adding explicit unembargo flags to a couple of places (Archive.copyPackage and the PackageCopier script) to avoid people unembargoing private files by accident; then for the time being making UnembargoSecurityPackage a trivial shell ... | 16:25 |
| cjwatson | ... around PackageCopier. Does that sound about right as an initial approach? | 16:26 |
| cjwatson | So PlainPCJ will unembargo files happily, but only if it has an appropriate flag set in its metadata. | 16:26 |
| cjwatson | This seems to be passing the initial set of plausible tests I can think of, although I'm waiting for 'bin/test -vvct soyuz' to run. | 16:27 |
| cjwatson | I suspect that delayed jobs need to be ripped out in a separate landing, just in case there are pending delayed jobs when a rollout happens. | 16:28 |
| cjwatson | Er, delayed copies. | 16:28 |
| === almaisan-away is now known as al-maisan | ||
| rick_h_ | sinzui: <3 the sprite stuff. | 16:49 |
| === salgado-lunch is now known as salgado | ||
| sinzui | rick_h_, thank you. I noticed you playing with awesomefont. Its CSS rules for icons are very similar to the rules I wrote for sprites...inline-block + text-indent to control what is seen | 17:05 |
| rick_h_ | sinzui: right, works out pretty well so far | 17:06 |
| rick_h_ | having a FF issue with awesomefont atm, but hopefully once I work it out it'll be a nice way to go | 17:06 |
| rick_h_ | talked with some dev friends also kind of neat to think that in the high-res world coming they'll work on smoothly hopefully | 17:06 |
| sinzui | yes. I have no experience with that issue. | 17:07 |
| rick_h_ | yea, I don't think most of us have yet, only really been in the mobile space | 17:07 |
| sinzui | I last worked with embedded on in 1999. | 17:07 |
| sinzui | rick_h_, oh, are you certain that firefox really understands the type? Does the server have to know the mime-type? | 17:09 |
| rick_h_ | sinzui: yea, I'm not sure what it is. The error is generic that firefox's font-sanitizer rejected the font | 17:09 |
| rick_h_ | so it might be a header from the server, not sure | 17:09 |
| rick_h_ | was hoping someone from FF land would see/point me out | 17:09 |
| rick_h_ | tried finding the code/source behing the sanitizer to see what kind of rules it enforces | 17:09 |
| rick_h_ | but yea, with the 'retina' macbook, high-res assets in sites is going to get more and more important I think | 17:10 |
| sinzui | I believe dobey have some deep knowledge of browsers | 17:10 |
| dobey | ? | 17:10 |
| rick_h_ | already a ton of work around sizing of images/etc around responsive and <3 the ability to size icons via css font-size for that | 17:10 |
| rick_h_ | dobey: oh, we were just discussin I was having some FF issues with an icon-font due to their font-sanitizer rejecting my font | 17:11 |
| rick_h_ | discussing, ugh mondays | 17:11 |
| dobey | oh | 17:11 |
| dobey | html VMs | 17:11 |
| rick_h_ | looks like someone's starting to help http://stackoverflow.com/questions/11072655/firefox-font-face-fail-with-fontawesome/11085126 | 17:12 |
| rick_h_ | but anyway, might be something interesting for our type of sites as things go forward. sinzui has been doing some awesome work cleaning up our sprite usages and it resembles using an icon font | 17:12 |
| sinzui | huwshimi has been suspiciously quiet for weeks. He was planed to make the sprites greyscale and colour on hover/activate. A font would be much easier to maintain. | 17:15 |
| rick_h_ | well I know we were keeping him busy some on our side for a bit | 17:15 |
| czajkowski | gary_poster: loving the retrospective mins of yellow team meetings | 19:25 |
| gary_poster | thank you czajkowski! It helps me write the darn things to get positive feedback :-) | 19:26 |
| czajkowski | gary_poster: I can almost get the tone and accent in my head when reading it | 19:26 |
| gary_poster | czajkowski, lol | 19:27 |
| czajkowski | it's nice to view meetings postively and in a fun interactive manner | 19:27 |
| czajkowski | gary_poster: want me to put them over on the LP FB and G+ pages to show others what we're doing | 19:27 |
| czajkowski | was in the new office today adn all I got was wouldnt it be nice if LP did this, and my answer is yes it would be but the squads are doing X,Y,z | 19:28 |
| gary_poster | czajkowski, uh. The secret is that I'm really kind of shy, so my initial internal reaction is "augh!". Even though I was an opera singer in a former life. But feel free if you think it would help anything. :-) | 19:29 |
| lifeless | gary_poster: hiya | 19:29 |
| lifeless | gary_poster: dunno if you saw in scrollback, I've added a knob for concurrency for test | 19:30 |
| gary_poster | hey lifeless. thanks for the two parachutes you sent | 19:30 |
| lifeless | r | 19:30 |
| lifeless | gary_poster: ah you did, cool. | 19:30 |
| gary_poster | yeah, definitely, and also the hint for the zope.testing thing | 19:30 |
| gary_poster | (the subunit times) | 19:31 |
| lifeless | gary_poster: oh right | 19:31 |
| lifeless | gary_poster: yeah, useful tool - testr uses it itself to timestamp incoming streams in case they are not timestamped. | 19:31 |
| lifeless | gary_poster: so you get socket latency effects, but better than round robin. | 19:31 |
| gary_poster | cool, lifeless. we may stick the times directly in the stream but if that's problematic at all we'll investigate throwing the adapter in. (I don't expect it to be problematic at all, but who knows.) What you said though...that sounds cool, but so wouldn't testr be applying that to the parallelized streams? Or maybe it's not in there yet for that use case? | 19:33 |
| gary_poster | you don't have to dig in now, just was curious | 19:34 |
| czajkowski | gary_poster: done thanks :) | 19:37 |
| gary_poster | czajkowski, :-) cool | 19:37 |
| lifeless | gary_poster: timing at source and sink is fine | 19:42 |
| lifeless | gary_poster: the decorator shuts up if a stream is timestamped already | 19:42 |
| gary_poster | ah! | 19:42 |
| gary_poster | so it sees any time and says "I'm outta here" | 19:42 |
| gary_poster | makes sense | 19:42 |
| lifeless | close :) | 19:43 |
| gary_poster | :-) | 19:43 |
| lifeless | it has the idea of a clock, and if its unset, anytime time is needed, it asks the system | 19:43 |
| lifeless | if its set, it uses what it was last set to | 19:43 |
| lifeless | and a stream with times in it has the effect of setting its clock. | 19:43 |
| gary_poster | ah! | 19:43 |
| gary_poster | yes | 19:43 |
| gary_poster | I saw those entered into the stream by testr | 19:44 |
| gary_poster | but since the clock is only advanced at not particularly helpful times.. | 19:44 |
| gary_poster | the adapter cannot put particularly helpful times back in | 19:44 |
| gary_poster | btw, lifeless, the clock can go backwards, right? | 19:44 |
| lifeless | testrepository/repository/__init__.py line 84 for reference. | 19:44 |
| lifeless | yes, the clock can go backwards (a necessity with multiplexing) | 19:45 |
| gary_poster | right | 19:45 |
| gary_poster | cool | 19:45 |
| gary_poster | ok I need to restart to see if my webcam will work then :-P | 19:45 |
| gary_poster | thanks and biab | 19:45 |
| lifeless | uhm, so get_inserter is whats doing the timing | 19:45 |
| === al-maisan is now known as almaisan-away | ||
| lifeless | gary_poster: found something interesting, replied to the bug | 19:56 |
| lifeless | gary_poster: the testr auto-timing location is deep in the pipeline (after the mux stage), so is going to be producing garbage atm. | 19:57 |
| === gary_poster changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | Welcome our new intern: ivory | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2 | ||
| sinzui | jcsackett, mumble? | 22:05 |
| jcsackett | sinzui: omw. | 22:07 |
| === jelmer is now known as Guest12454 | ||
| === Guest12454 is now known as jelmer | ||
| wgrant | cjwatson: That sounds good. | 23:35 |
| wgrant | cjwatson: Delayed copies should be ripped out in a separate landing anyway. | 23:36 |
| wgrant | cjwatson: Let's not conflate changes that shouldn't be conflated. | 23:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!