[05:17:31] cdanis / volans / XioNoX: I somehow missed the discussion above about long puppet disables being an anti-pattern. No argument there :) It occurred to me that I don't actually know why (if) puppet needs to be disabled during the reloads, so I'll need to get some insight from gehel before I can talk specifics, but I think we're all agreed that the current way of doing things needs to be better [05:18:18] TLDR definitely a problem, I need to gather some context first to give me an idea of the best way to solve it [08:11:26] ryankemper: thanks for the follow up. I agree with all the above. Another bit that could be improved is the downtime, we could improve spicerack to easily allow to downtime specific checks. I guess you just need to downtime only some of them and would like to still know if the host goes down or the disk is full or some HW failure. [08:16:39] * jbond42 updated https://wikitech.wikimedia.org/wiki/Puppet to say 14 days [08:27:06] just for the record Guest13200 was me above :D [09:17:54] is anyone else getting a flood of emails from nagios/icinga? [09:18:40] dcaro: yes. it's being handled in #-operations [09:18:47] ack [09:27:15] It was my bad, pushed a broken sudo config [14:24:07] can any puppeteers tell me what terrible thing i've done to offend puppet here? https://phabricator.wikimedia.org/P14478#78345 [14:28:56] You pulled the strings too harsh and the puppet didn't like it [14:29:40] tabbycat: that seems as likely as any other explanation i can come up with [14:32:51] kormat: not sure why looks like it should work to me but i posted something that passes the the syntax check [14:33:10] jbond42: FML. but thank you <3 [14:36:41] WTB $hash.get(key, defaultvalue) for puppet [14:39:50] kormat: the ternary operator in the snippet i posted is the best way to my knowlage [14:41:04] it's dumb that you have to repeat the lookup inside the selector [14:42:07] kormat: actully ignore that you can use stdlib pick [14:42:25] pick( $sec_params["replication_type"], $def_params["replication_type"]) [14:42:32] it uses the first no def value [14:42:38] oh hurrah! [14:42:54] https://github.com/puppetlabs/puppetlabs-stdlib/blob/main/REFERENCE.md#pick [14:50:35] jbond42: how's this look? https://phabricator.wikimedia.org/P14478#78348 [14:52:13] kormat: that looks good to me [14:52:24] great, thanks :) [14:52:49] assuming Profile::Mariadb::Writeable_DC is a new type you are adding [14:53:06] it is, yeah [14:53:51] all good :) [15:37:24] I have a bunch of ip addresses and I'd like to know their puppet role, is there sth I can use already or e.g. it is puppetdb query time? [15:38:02] "a bunch" == < 100 [15:40:56] godog: if its a one time thing might be easiest to just use cumin; [15:40:57] for ip in $( ip addresses) ; do sudo cumin 'F:ipaddress = $ip' ; done [15:42:18] jbond42: yeah it is a "bunch of times" thing, cumin SGTM, thanks! [15:44:55] jbond42: err, that's not going to give me the puppet role though [15:45:10] oh yes lol [15:52:14] I ended up doing sth similar, cumin query for O:role and get the ip addresses from there [15:55:18] godog: ack was too slow, but you could use something simlar to https://phabricator.wikimedia.org/P14510 (bud would need to resolve the ip to fqdn first) [15:56:03] fyi there are genrally some adhoc ptpuppetdb scripts in my home folder on puppetdb1002. sometimes the name of the script even makes senses [15:56:14] *pypuppetdb [15:59:09] jbond42: nice! thank you, definitely bookmarking that [17:12:20] Hi, is there a public list of outbound ips that are used for WMCS [17:14:48] Zppix: 185.15.56.1/24 afaik, but you might want to ask confirmation from cloud services people in -cloud [17:16:05] ok thanks [17:16:41] 185.15.56.0/24 is eqiad WMCS [17:17:04] thank you :) [17:22:37] it might make sense to explicitly note the WMCS allocations on https://wikitech.wikimedia.org/wiki/IP_and_AS_allocations [17:24:56] Can I leave a comment on a Gerrit CR in "Work in progress" mode, without removing WIP? The only option I see is "start review" [17:30:26] I dont believe so XioNoX [17:30:58] cdanis: if you tell me where to put it i can add it [17:33:10] note netbox-next is slightly broken right now while i'm testing some things. [17:37:14] Zppix: we should WMCS decide, otherwise it will go forgotten and stale :) [17:37:22] ok [17:37:38] chaomodus: feel free to nuke my capirca script [17:39:08] XioNoX: if i'm interrupting you i can wait til later [17:41:54] chaomodus: nah, I'm on PTO starting now :) [17:42:08] ah rad :) [22:45:08] For some reason Extension:MassMessage bot (MediaWiki message delivery) exists on some wikis but its account does not even appear as unnatached on Special:CentralAuth/MediaWiki_message_delivery [22:45:13] legoktm: ^ [22:45:17] any ideas? [22:46:23] which wikis? [22:46:32] sounds like the centralauth.local_names table is out of sync [22:46:49] legoktm: I'm checking nia.wiktionary right now [22:47:16] I also forget if we even bother attaching system users or not [22:47:35] I don't see why we shouldn't :) [22:47:40] it looks like I did all of those manually in 2014 [22:48:04] most of MMD accounts are attached, but for nia.wiktionary (and I guess others) the account is not even listed as unnatached in centralauth [22:48:32] if I had to guess, creating a system user bypasses CentralAuth [22:48:59] not saying that it's good, just that's how it is :) probably needs a hook or something for CA to update its side [22:49:31] there's no advantage to attaching the accounts except it makes Special:CentralAuth look nicer (though it was needed in 2014 to make sure the accounts didn't get renamed) [22:49:35] if I make the bot edit for its first time, will it appear? [22:49:41] doubt it [22:49:53] legoktm: and GlobalUserPage, which is good [22:50:02] oh that's true [22:50:16] that's why I'd prefer to have them attached [22:50:19] if you sort by attach date, you'll see the last account was attached in 2016, and we've created tons more wikis since then [22:50:34] please file a bug :) [22:50:47] Filing [22:51:18] "Please attach/whatever the accounts of MediaWiki message delivery to Wikimedia SUL because legoktm said so" [22:52:23] Perhaps we could add a maintenance script in addWiki.php so it does it for new wikis? [22:53:12] tabbycat: probably 1) Have new MassMessage system users be automatically attached to CentralAuth and 2) attach the existing users manually [22:53:37] So two tasks then [22:53:41] k [22:53:44] :) [23:10:19] Filed both as T275931 and T275935 [23:10:19] T275935: Please attach new MassMessage system accounts on Wikimedia wikis - https://phabricator.wikimedia.org/T275935 [23:10:19] T275931: Have new MassMessage system users be automatically attached to CentralAuth - https://phabricator.wikimedia.org/T275931 [23:10:35] ty :) [23:11:08] Feel free to amend descriptions or comment if they ain't clear