[08:52] tomwardill: Could you have a look over https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/380350 and https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/380351 for OCI webhooks? [08:52] oh, I meant to do that yesterday, had the tabs open and everything [08:52] on it [08:52] ilasc: Could you have a look at https://code.launchpad.net/~cjwatson/lp-signing/+git/lp-signing/+merge/380014 ? It's a prerequisite for the Juju charm [08:53] Also, yesterday I found https://forge.softwareheritage.org/T1734 which relates to my recent GitRepositorySet.getRepositories changes, and updated it with a slew of details [08:56] cjwatson: +1 [08:59] have mp 380391 open for study on the to do list for today, above detail is great for that! thanks for sharing Colin! [08:59] Ah, excellent, that hopefully solves much of the problem. [09:00] wgrant: Which does? [09:00] That softwareheritage.org ticket, and your reply to it. [09:00] Ah yes [09:01] There's a SH bod on #debian-uk who said that the people working on this are students who just kind of ... show up. Must be a nice problem to have :) [09:01] can we borrow some :) [09:03] :) [09:07] That does make some degree of sense. [09:08] And would indeed be quite handy. [09:08] Though I guess a bunch of us were just students who showed up at one point. [10:37] Hmm I think I can possibly reproduce the turnip-pack-virt memory leak locally [10:40] Doesn't seem to reproduce when looking up nonexistent repos, but if I clone the same existent repo 100x in a loop then I see virtserver's VIRT growing by a MB or so in top. (sshserver gets bigger too, but I think that's keepalive connections and goes away again) [10:40] Attacking it with meliae now to see if I'm imagining it [10:40] ... I've made the wifi slightly faster in my study by replacing the cable [10:40] one of us is having a productive morning. I suspect it's not me. [10:43] you're optimising your environment! :) [10:50] suspicious growth in function objects [10:54] all in the guts of inlineCallbacks I think [10:57] Investing in your infrastructure is generally worthwhile! [11:00] I don't think PackVirtServerProtocol.requestReceived ever returns in the successful case [11:00] I stuck a log entry at the end that I'm not seeing [11:04] Oh. Well nothing ever calls .callback() on that particular deferred, only .errback(). That would probably do it [11:05] (see PackClientFactory) [11:07] is it a one-liner [11:08] hah [11:12] Need to figure out how to test it but I'm pretty sure it's just https://paste.ubuntu.com/p/vRJsZtMhcW/ [11:12] meliae++, made this a great deal easier to track down [11:27] cjwatson: is it worth adding the date_* columns to the OCI credentials and push rules? [11:35] tomwardill: I don't think so really. They're not going to be displayed on their own pages with the "Registered by on " boilerplate or anything; they're more like settings. [14:50] cjwatson: the credentials field, what do I need to do to make it an encrypted field? [14:58] tomwardill: There isn't yet any prior art for making an entire column be encrypted (as opposed to one value in a larger JSON column). But you should be able to work it out, more or less, by grepping for EncryptedContainer [14:58] ah, that's the magic term i was missing [14:58] * tomwardill tries [14:59] tomwardill: You'll need an IEncryptedContainer implementer (based on NaClEncryptedContainerBase) registered with some appropriate name and that plugs in the correct configured key pair; and you'll need a property on the model that does getUtility(IEncryptedContainer, whatevernameyoupick).{encrypt,decrypt} [15:00] tomwardill: Or if you wanted to try slightly harder you could write a custom Storm variable that does this [15:00] Shouldn't be very difficult, we just haven't needed it so far [15:00] the latter feels more resuable [15:00] Well, variable and property, since they usually come as a paid [15:00] *pair [15:01] e.g. have a look at the implementation of JSON and JSONVariable [15:01] And yes, I think that would be more correct [15:27] tomwardill: I think you can go ahead with https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/380200 now - the linked code change is on prod [15:28] ah, cool [15:28] landing [16:08] cjwatson: slightly trivial question, would the storm variable live in storm, or launchpad? [16:19] tomwardill: Launchpad [17:12] I don't much like the Storm variable approach. It would make accidental leaks easier, and leave the object unloadable on most services [17:13] wgrant: I don't follow either objection there [17:14] Accidentally printing the object's fields would leak the secret, and examining the object's fields on most LP hosts, that don't have the wrapping key, would crash. [17:15] aha, right, that makes sense [17:17] I suppose [17:18] * tomwardill closes storm checkout [17:18] * cjwatson finally persuades turnip tests to pass with only a small hack [17:27] excellent, DB patch landed with only minor buildbot poking [17:28] Nice [17:33] Could I have a review of https://code.launchpad.net/~cjwatson/turnip/+git/turnip/+merge/380646 please? As far as I can tell this fixes the turnip-pack-virt memory leak on production that's been taking down the service every couple of days [17:34] Excellent! [17:36] looking [17:39] test_git.py is inconsistent as to assert(expected, received) or assert(received, expected) [17:40] Is it? [17:41] Oh, I got this backwards, silly me [17:41] test_git_receive_pack_calls_spawnProcess appears to be reversed from test_git_upload_pack_calls_spawnProcess [17:41] so there's both in there already [17:41] receive is using assertThat not assertEquals [17:42] and assertThat requires the matcher as second arg [17:42] oh, so it is [17:42] sorry [17:42] so it was just my new code that was wrong, and I've fixed it now [17:42] cool [17:42] cjwatson: what fails in the test without the callback change? [17:43] it hangs [17:43] since yield requestReceived never returned [17:43] ah... that'd do it :) [17:43] *returns [17:43] (though doesn't hang indefinitely since AsynchronousDeferredRunTest has a timeout) [17:43] have a +1 [17:44] thanks