[09:31:52] Krinkle: i just want to confirm - is x2 still completely unused? (that would simplify some maintenance i need to do) [10:31:06] volans: how hard is it to query puppetdb from python? [10:31:34] kormat: depends what you need [10:31:57] oh excellent. i'm _sure_ my use-case will be trivial, as per usual. [10:32:14] volans: given a hostname, i'd like to look up some puppet class params for it [10:32:19] puppetdb API are open only from some specific hosts, a larger subset of hosts has access to a proxy API that allow only a subset of querying capabilities [10:32:30] this would be running on a cumin host, as root [10:32:32] so first question is from where you need to run it [10:32:33] ok [10:33:02] so you have 2 options 1) pypuppetdb 2) requests [10:33:10] if the use caes is simple requests might be the quickest [10:34:40] oh, also i'd like to be able to discover what role the host has [10:35:56] do you know the class names in advance? [10:36:49] mmh. i can hard-code them if i have to [10:37:01] regex is an option too [10:37:26] but otherwise you're basically downloading the whole catalog and then parsing it, seems pretty inefficient (and heavy on puppetdb apis) [10:37:30] *because [10:37:46] sigh, ack. [11:34:40] kormat: yes, unfortunately, fortunately [12:24:54] Krinkle: hah, thanks :) [12:56:17] If I want to extract the OS versions of a bunch of hosts (for a phab task), is there a more elegant approach than cumin 'dpkg --compare-versions $(lsb_release -rs)...'? [12:58:46] Emperor: depends on your requirements, one option is puppetboard [12:59:07] for example https://puppetboard.wikimedia.org/fact/lsbdistrelease [12:59:27] or lsbmajdistrelease or lsbdistcodename [13:00:04] Emperor: you can do it without running any remote commands `cumin 'A:bullseye and P{whatever other thing you were going to do}'` [13:00:18] and those you can use also as cumin queries [13:00:24] that'll tell you which of the hosts are running bullseye. [13:02:42] indeed, things like 'A:buster and A:swift' [13:05:00] yet another option is to check in debmonitor the version of some specific package that you know has different versions between OSes, either because different version or because of the debN suffix, like https://debmonitor.wikimedia.org/packages/swift [13:07:32] what I want is a way to track progress on an OS upgrade task [13:08:16] Emperor: in that case, https://phabricator.wikimedia.org/T303174#7835259 [13:08:19] and since relying on me remembering to tick a box on phab every time I reimage a host is doomed to abject failure... [13:08:23] adjust the shell command to taste. [13:08:47] lol [13:09:16] I hoped that horrible one-liner was going to die sooner :D [13:09:23] kormat: you know how I said "more elegant approach than..."? ;p [13:09:50] that option though generates already the phab output with checkbox checked :D [13:10:18] Emperor: or you just kink the debmonitor page (with the right package) and keep track there of the progress [13:11:07] that's quite an.. unfortunate typo you've got there ;) [13:12:35] If I don't care about ticky-boxes, just the cumin 'A:stretch and A:swift' and 'cumin 'A:bullseye and A:swift' commands are probably good enough, actually [13:13:01] ms-be1071 is buster :-P [13:13:22] yes, I had spotted that :) [13:13:57] sudo cumin '(A:stretch or A:buster) and A:swift' works though [13:14:06] sure [13:14:07] * Emperor should resist the "why" questions [13:14:23] I have why questions too [13:15:11] (in practice that's one of the ones that is waiting for DC ops to sort out the HW RAID) [13:18:36] got it [13:27:23] https://i.imgflip.com/6c6iwi.jpg https://gerrit.wikimedia.org/r/c/operations/puppet/+/779024 [14:54:52] Does anyone have any tickets or similar for me to read up on as regards issues changeprop might have been having in the last 2 weeks? Just back from PTO/sick and catching up [14:56:35] hnowlan: https://docs.google.com/document/d/15jicS28wwVIoo19EGuRVD3E9k0N8kTYraw-WN2W_Nkg/edit#heading=h.vg6rb6x2eccy is a start [14:56:50] welcome back and I hope you're feeling better :) [15:07:36] thanks! [16:06:25] hnowlan: do you know who owns maps* [16:13:26] RhinosF1: good question - but I'm probably best position to do something about it. What's up? [16:13:27] Or maybe mbsantos as you have access to them [16:13:47] hnowlan: hi, didn't see you reply. Papaul needs to do some work on one of them [16:14:02] See https://phabricator.wikimedia.org/T305469 and #wikimedia-dcops [16:17:12] RhinosF1: thanks for the heads-up [16:18:23] hnowlan: thanks, is there a task for finding a service owner? The naming conventions page has no one on [16:23:53] RhinosF1: I can update it [16:24:10] hnowlan: please :) [16:29:35] hnowlan: maps2006 should now be back online [17:05:34] jelto: I've updated the impact line here, could use confirmation that I understood it correctly, namely that 1) unlike the other 2 wdqs-related incididents that this did not cause "lag" in a way that affected wikidata.org bots and such, and 2) that indeed it did cause impact on public requests, but only those to the public wdqs instance. Is that right? https://wikitech.wikimedia.org/wiki/Incidents/2022-03-06_wdqs-categories [17:05:45] * Krinkle sees the /away message [17:06:12] * Krinkle sees jbond not in the channel [17:06:18] someone else then perhaps :) [23:29:27] kormat: low prio question to test my confidence - what if anything should one keep in mind when changing from implicit to explicit join condition, is that more or less void of risk, or are there gotchas to look out for? e.g. clean up like https://gerrit.wikimedia.org/r/c/mediawiki/core/+/697153. We've done a number of these in the past, but figured I'd check with an expert to maybe learn something new :)