[09:37:11] If anyone is interested, the results of the annual Python survey made by JetBrains are out (~24k responses from 150 countries): [09:37:14] https://www.jetbrains.com/lp/python-developers-survey-2019/ [11:31:25] python for web development? Is that django? [11:32:46] ah yeah the answer is below Django/Flask [13:59:19] just to make sure it's not just me: if you enter a host into icing's search box and hit enter, how long does it take for the page to load? it's about 5-6s here [14:00:32] kormat: you should have seen before with the autocomplete JS :D [14:01:33] kormat: T251644 and https://icinga.wikimedia.org/cgi-bin/icinga/extinfo.cgi?type=4 [14:01:33] T251644: Icinga refresh hardware selection (2020) - https://phabricator.wikimedia.org/T251644 [14:01:36] for context [14:07:05] icinga cpu bottlenecked... on what? forking? ;) perl? [14:08:36] C while true loop pretty much :D [14:15:19] cdanis: why are dbctl config diffs so _bad_? [14:15:49] lol [14:15:54] e.g. https://phabricator.wikimedia.org/P11217 [14:26:54] kormat: jokes aside IIRC difflib was used [14:31:21] kormat: sorry [14:32:15] kormat: some of it is the structure of the output itself (not too much we can do about that), some of it is we should be smarter about the meaning ... but wow that example is heinous [14:32:21] not sure why difflib wasn't smarter about that [14:37:10] cdanis: most of the diffs i get from dbctl are that level of useful [14:39:51] kormat: can you open a task for really bad diffs and start putting pastes there? would be useful to have some samples [14:40:02] with pleasure. [14:41:08] <_joe_> cdanis: shell out to diff -aur :P [14:42:21] if that gave drastically different output than difflib i'd be interested [14:42:56] `diff(1)` has `--minimal` [14:42:59] which might help [14:43:19] the difflib documentation has a mention of how it doesn't produce minimal diffs, because generally they're bad [14:43:24] but I can imagine that not being the case here [14:43:32] <_joe_> we [14:44:04] <_joe_> we're showing what's supposed to be minimal diffs in most cases [14:44:46] yeah, I think so too [14:45:09] <_joe_> I mean that diff is just... misleading [14:47:03] lol, user-hostile diffs [14:49:27] cdanis: `diff(1)` gives a vastly better output. https://phabricator.wikimedia.org/P11217#64471 [14:51:13] yeah i'm kind of surprised difflib does so poorly [14:51:25] we are basically just invoking the difflib analogue of `diff -u` [14:51:35] waaait [14:51:41] how much context do you tell difflib to provide? [14:52:35] mm, no. even `diff -u10` gives sane output [14:52:47] ah, yeah, was about to link you https://gerrit.wikimedia.org/r/plugins/gitiles/operations/software/conftool/+/master/conftool/extensions/dbconfig/config.py#318 but you found it ;) [14:53:11] i didn't, i just counted :) [15:00:54] if we have to shellout let's use icdiff :D [15:08:05] side-by-side is nice yeah [15:08:17] volans: we don't actually have to shell out to use icdiff... [15:11:04] cdanis: if we add it as deps of the extension only yes [15:11:16] otherwise we need to backport it for jessie IIRC [16:26:19] XioNoX: ping me when you have a minute to talk about T247972 ? [16:26:19] T247972: Cloud DNS: fix inconsistent ownership of reverse domains for openstack floating ip networks - https://phabricator.wikimedia.org/T247972 [16:45:47] XioNoX: nm, will reply on task [17:03:00] andrewbogott: if you're still around I can try it now [17:07:07] XioNoX: let's try it [17:09:13] andrewbogott: different error [17:09:28] for which domain? [17:10:12] andrewbogott: only trying the codfw one for now [17:10:27] it's actually the same error but in a different presentation than last time [17:10:46] hm [17:11:16] let's try the eqiad domain now, since it's the user-facing one? The other one won't require any actual syncing up [17:11:56] regarding the codfw1dev error, are you able to tell at all what the issue is? [17:12:08] Like, does the lookup fail for you too? [17:13:34] not really yet, I asked you before looking more into it [17:14:10] that's reasonable :) [17:14:59] I think my question is, when it says "No response from nameserver for zone 57.15.185.in-addr.arpa when trying to fetch glue" is: how I can I reproduce the fetch it is doing? [17:15:00] andrewbogott: eqiad "Modify SUCCEEDED: [domain] 56.15.185.in-addr.arpa" [17:15:05] great! [17:15:24] lgtm [17:15:41] andrewbogott: yep, that's a good question, haven't looked yet [17:16:31] 'k [17:16:42] (sorry, I've now realized that I need to make lunch so am partially distracted) [17:17:28] no pb! [17:19:03] ftr, that codfw1dev nameserver is a bit of a work in progress so it's not a shock if something is broken there. I can try to fix the specific bit or we can just postpone this task until things are more finished there. [17:21:30] I think the server in charge of 57.15.185.in-addr.arpa needs to delegate 0-7.57.15.185.in-addr.arpa to your server [17:21:34] with glue records [17:21:39] I'll look more into it later [17:21:55] ok — so that would be ns*.wikimedia.org? [17:22:07] Anyway — there's no rush on this, thank you for looking! [17:23:32] If what I think is correct, yes [17:25:54] 'k [18:07:43] hnowlan: I noticed you're running a cookbook on cumin1001, I'll skip the spicerack update for now (should be safe but just in case I'll wait that it completes) [18:08:10] FYI pro-tip: if you want to see the progress host-by-host, tail the -extended log ;) [18:08:26] volans: thanks. and nice! [18:09:26] I think the command should finish soon but it's a slow one (cassandra roll-restart) [18:10:01] yeah, no worries, I'll keep an eye on SAL for the end, do you have any other one planned right after this one? [18:10:41] nah, I'll do the next one tomorrow [18:10:55] ack, thx