[08:51] the hardest part about retries is writing tests for them [08:52] ahja [08:52] https://github.com/jd/tenacity is neat though [09:06] Add retries for ConnectionError in registry client: https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/382904 and matching dep addition: https://code.launchpad.net/~twom/lp-source-dependencies/+git/lp-source-dependencies/+merge/382903 [09:14] Thanks, looking [09:16] Oh, Julien Danjou, good [09:18] it's a maintained fork of the retrying library [09:18] the backoff library is currently unbuildable from source [09:20] Question in there for you [09:21] yep, we can shorten the retry, I just picked a number [09:21] 5 seconds * 5 retries? [09:23] 3 seconds maybe? I'm not super-happy about 15 seconds either but it's hopefully tolerable at least until we figure out something better [09:24] sure [09:24] cjwatson: changed and pushed [09:28] r=me with a few more comments [09:37] cjwatson: oh good call on the sleep patch, that has massively simplified things [09:37] Oh good [09:38] in theory it'd be possible to remove the inner patch / exception raising, but I'm going to leave it so we're not _just_ trusting tenacity to tell us it's retried [09:42] * tomwardill adds comments to that effect [09:47] cjwatson: how do I land the dependencies branch, just top approve and wait for it to be merged? [10:01] tomwardill: Yep [10:02] excellent, landing then [10:09] landing retry [10:17] both merged [10:28] So uh [10:29] Automagic links on the OCI image build page for "we built it AND pushed so it's available at example.com/badger" [10:29] Is that as painfully hard/unpossible as I suspect? [10:33] Snap has something similar, iirc [10:34] presumably easier there because they're only going to be pushing it to one place [10:35] SpecialK|Canon: I started working on that the other day [10:35] yeah, but we know the registry url, so we should be able to work it out from that [10:35] 'should' [10:35] cjwatson: <3 [10:35] At least to provide the status of pushes. I expect I'd need help on figuring out the target URL [10:36] tomwardill: I don't suppose it's something the registry tells us in a push response? [10:36] If so, the push job could stash it. (That's what we do for snap) [10:36] I've not looked, but https://registry_url/image_name should just work [10:37] as that's what the `docker pull` command would be (we have to assume there's no web front end on a registry) [10:37] Reliably for all registries? OK [10:38] oh, for us it'd be https://registry_url/image_name:edge to perform a no-interaction pull [10:39] where 'edge' is the result of OCIRegistryClient._calculateTag (which could move to OCIRecipeBuild reasonably easily) [10:40] Or the build job could stash what it did [10:40] Trade-off is that that puts the URLs in the DB so they're harder to fix if we get them wrong [10:40] or that [10:41] but is immune to changes in the calculation affecting past images [10:41] given we know that image_name and tag is going to change soonish [10:42] cjwatson: acknowledging I saw your comments in the OCI UI doc and all makes perfect sense, working in that direction, thank you ! [10:44] ilasc: you might as well take advantage of my painful experience working out that permissions UI :) my notes say spec started 2018-08-10, blog post about the completed feature posted 2019-01-10 [10:46] :) [10:46] though of course a lot of that was working out the correct underlying model [10:48] OK, 2018-10-05 "started experimenting with git permissions UI"; 2018-10-31 proposed the MP [10:48] that's probably slightly more representative [10:48] * tomwardill nearly defenestrated that matching algorithm, many times [10:48] and I actually could've done, because I had it printed out and covered in red pen [10:49] wow :) OK [10:49] yes, I am currently using a similar approach to parse the form data