[00:16] wgrant: Fancy some pip fun? https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/379684 arranges to build wheels as part of our deployment artifact, which is something on the order of four or five times as fast on my laptop as building them from scratch (as happens when we rsync out from one path on carob to a different path on target machines). [00:17] Should get deployment times back to in the area of what they were before the conversion to pip. [00:20] cjwatson: what's the [0-9]* in the LP wheel name? [00:20] But sounds like a good idea [00:20] Version [00:21] $ grep ^__version__ setup.py [00:21] __version__ = '2.2.3' [00:21] I just wanted to avoid future amusement with some dependency's name happening to start with "lp-" or something [00:21] Ah, fair enough, indeed [00:21] No underscores for us [00:22] r=me [00:24] Excellent, thanks [01:38] atemoya: [01:38] Thu 27 Feb 12:44:33 UTC 2020 Building code [01:38] Thu 27 Feb 13:09:14 UTC 2020 Updating code [01:38] Thu 27 Feb 18:13:05 UTC 2020 Building code [01:38] Thu 27 Feb 18:32:48 UTC 2020 Updating code [01:38] (both builds before the change above) [01:38] Fri 28 Feb 01:32:28 UTC 2020 Building code [01:38] Fri 28 Feb 01:36:38 UTC 2020 Updating code [01:39] So that phase is indeed about five times as fast there. [01:47] Very nice. [03:32] noice [12:42] ooh, a bug fix from 2017, that's exciting :) [12:43] Well, I think we still have some bugs from 2011 open... 😅 [12:43] little steps, little steps ;) [12:44] One at a time. We will get there. :-) [12:44] We have some bugs from before that ;) [12:44] I put a card on the list for Frankfurt to do a little triage of our Critical bugs [12:44] We have bugs from 2005 open ... [12:44] huh, you can't sort bugs by age [12:44] I can believe they're still bugs, but we should maybe talk about the definition of "Critical" [12:45] oh, I guess Number is basically the same [12:45] tomwardill: You can, use the cog at the left of the list of sort columns [12:45] https://bugs.launchpad.net/launchpad/+bug/25 [12:45] Bug #25: Allow discussion/commenting on translations

[12:46] wow... #25! [12:49] Launchpad was of course the first project to use Launchpad for bug tracking (leaving aside the special case of bug 1) [12:49] Bug #1: Microsoft has a majority market share

[12:49] lh-maviya>

[12:49] [12:50] I'm not sure what happened to bug 2; it's not just that it's private or something, it literally doesn't exist [12:50] thanks mup [12:53] OK, I think the wheelhouse work has shaved about 40 minutes off our deploy-to-production time. Not bad [12:54] Great! [12:54] "not bad" he says [12:54] sounds pretty excellent to me, nicely done [12:54] :) [12:54] (Comparing timestamp differences from the first couple of sections of https://deploy-logs.admin.canonical.com/index/legacy-lp/ndt/2020-02-25-ndt.log and https://deploy-logs.admin.canonical.com/index/legacy-lp/ndt/2020-02-28-ndt.log) [12:54] I second that! [12:55] Am I right in my reading of that first one being 2h end-to-end? [12:56] SpecialK|Canon: Sort of, but bear in mind that it's four steps run in sequence so if the operator isn't paying much attention then that will extend the time [12:57] SpecialK|Canon: A fairer comparison is to add the four timedeltas between "Starting step" and "Ended step" [12:57] cjwatson: ah thank you [12:58] The work I just did takes about 20 minutes off each of the build step (within nodowntime-security-update.sh) and the deploy step (within ./parallel.py --config=lp --options='--push-new-code' --targets='nodowntime') [12:58] I make that about ~45m of gaps, so around 1h15 in the first instance [12:59] Heck even of 2h, 40m is quite a chunk! [12:59] It's only getting more impressive ;) [15:52] cjwatson: looks like we'll need to drop the NOT NULL constraint on OCIRecipe.git_path, as well [15:52] Snap does the same [15:56] tomwardill: Hm, yes, that makes sense [15:57] I'll do a DB patch for it [15:57] You could get away with a hack to avoid it but it would be gross [15:58] tomwardill: Maybe add something like the consistent_git_ref constraint that Snap has while you're there [15:58] tomwardill: While it was NOT NULL it wasn't needed, but now it is [15:58] ah yeah, makes sense [16:19] cjwatson: should/can I reuse the DB patch number from the reverted one? Or best to assign a new one. [16:19] Not sure what happens if there's a gap in the run [16:38] tomwardill: Reusing is fine in this case since it never went anywhere interesting [16:38] cool :) [16:38] Just update the description in dbpatches/allocated.txt [17:22] cjwatson: https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/380038 [17:23] DB patch, code patch incoming soonish [17:26] tomwardill: db=me [17:27] gah, pushed code to wrong branch [17:27] * tomwardill undoes [17:38] matching code, lifting the detachFromGitRepository code into OCIRecipe from Snap https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/380039 [17:38] what I have mostly learnt is that I cannot spell detach reliably. [17:59] tomwardill: LGTM, but blocked on the DB patch being rolled out [18:00] aye, it's not blocking any of the other OCI work though, so no worries :) [18:00] * tomwardill unticks 'git_repository should not be null' on todo list, then ticks it again. [18:04] tomwardill: Do you have time for a quick review of https://code.launchpad.net/~cjwatson/lpjsmin/py3/+merge/379696 and/or https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/379996 before you finish up? [18:04] sure [18:07] cjwatson: +1 to both [18:10] Great, thanks [18:21] huh, test failures on my DB patch. I definitely ran them, and I definitely had the change applied this time! [18:22] Hm, you swapped those two lines in the git_ref setter in your latest code patch [18:22] Which of course isn't on db-devel yet [18:23] * tomwardill arghs [18:23] * tomwardill headdesks [18:23] My guess is that you need to land a patch on master that just swaps those lines and nothing else [18:24] yeah [18:24] Then we'll need to make sure to deploy that to production before rolling out the DB patch [18:24] (If we were a larger team this would require backing out the DB patch; as it is I think we can probably cope) [18:25] patch incoming [18:26] Cool. I need to finish up soon but I can at least cope with occasionally thwacking buildbot [18:27] https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/380046 [18:27] just running tests [18:28] r=me [18:28] But yeah, will be quickest to confirm that this does fix the db-devel failures before landing [18:28] hmm, I should check the tests against the old DB too [18:29] I'm not worried about that in this case [18:29] But well, maybe worth a try in fact [18:31] running now [18:31] oh boo, that fails [18:32] storm.database.IntegrityError: null value in column "git_path" violates not-null constraint [18:32] Ugh [18:33] I think backout out the DB patch and doing a two-stage deploy might be safest? [18:33] What does the first stage look like, though? [18:33] drop the NOT NULL on the git_path [18:33] then deploy the code change [18:34] then add the constraint [18:34] Ah, I see. A bit elaborate, but at 6:30pm on a Friday I don't have a better plan. [18:34] So not really back out - you can just land a change that edits that DB patch in place. [18:34] Given that there's nothing on production there's probably some alternative strategy, but let's go with this [18:34] how about a revert for the DB patch, given 18:30 friday, etc. Then fix it up next week? [18:35] I think it would be fine to back out just the new constraint [18:35] so just delete that line from the patch? [18:35] DROP NOT NULL on its own is pretty safe. [18:35] Yeah [18:36] running tests [18:39] okay, they passed with both old and new code: https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/380048 [18:41] tomwardill: db=me, thanks [18:42] cjwatson: landing, apologies for the late evening mess! [18:42] tomwardill: np. you'll need to force buildbot [18:43] wait until you see the change at the left of http://lpbuildbot.canonical.com/waterfall first [18:43] on it [18:45] Right, mostly gone. See you in FRA [18:46] o/