[08:33:57] <moritzm>	 is anyone currently doing any reimages? I'd reboot apt1001 and install1003 in ~ 10 mins, so please speak up if I should postpone
[08:34:04] <marostegui>	 I am
[08:34:09] <marostegui>	 Just started one
[08:34:10] <marostegui>	 :(
[08:34:20] <marostegui>	 I will let you know once it is finished
[08:34:23] <moritzm>	 np, just ping me when it has completed, ok?
[08:34:29] <marostegui>	 will do
[09:24:42] <marostegui>	 moritzm: I am done!
[09:27:47] <moritzm>	 ack, rebooting install1003 now
[09:29:46] <XioNoX>	 moritzm: mmandere is also imaging servers for drmrs (see -traffic) not sure if it would be impacted (or if he's done)
[09:32:40] <mmandere>	 XioNoX: Thank you for pointing that out... I'm still in the process of reimaging drmrs but it can wait since I missed moritzm post
[09:34:32] <moritzm>	 mmandere: a reboot of install1003 has no immediate impact on drmrs installed (and it's complete anyway), can you ping me when the current server install is done, then I'll reboot apt1001 before you kick off the next reimage?
[09:35:20] <mmandere>	 moritzm: no problem you can go ahead with the reboot
[09:35:40] <moritzm>	 thx, doing that now, then
[09:35:55] <mmandere>	 great 
[09:39:12] <moritzm>	 and complete, you can proceed :-)
[09:40:00] <marostegui>	 moritzm: we can resume reimages then?
[09:41:08] <moritzm>	 yes! install1003 and apt1001 are both done now
[09:41:20] <marostegui>	 good!
[09:41:21] <marostegui>	 thanks
[09:41:24] <mmandere>	 moritzm: thank you
[09:56:47] <vgutierrez>	 _joe_: we need a few extra timeouts on envoy: https://gerrit.wikimedia.org/r/c/operations/puppet/+/753919
[10:42:27] <_joe_>	 vgutierrez: would it make sense to gather all timeouts to a single data structure?
[10:42:37] <_joe_>	 we can do it in a later patch, I was just wondering
[10:42:42] <vgutierrez>	 I've been doing that for haproxy and ATS
[10:42:47] <vgutierrez>	 so you got my +1 for that
[15:38:11] <kormat>	 hnowlan: you must really be wishing you'd gotten someone who knows reuse-parts to review that recipe for you 😅
[15:39:14] <hnowlan>	 kormat: i break it you buy it 
[15:39:18] <hnowlan>	 (thank you and sorry)
[15:40:12] <kormat>	 hnowlan: sorry i didn't catch these issues in the first CR. it's been a Long time since i looked at the details. PTSD, and all that. ;)
[16:05:35] <hnowlan>	 kormat: it worked <3 this is gonna make the restbase upgrades a hell of a lot easier 
[16:06:40] <elukey>	 yep kormat++
[16:15:49] <kormat>	 hnowlan: delighted to hear that :)
[21:17:25] <inflatador>	 cwhite are you puppet-merging at the moment? Just making sure as I was gonna apply ebernhardson 's commit which is right before yours
[21:18:44] <cwhite>	 inflatador: ahh, I merged it.  It looked pretty safe.  See an issue?
[21:18:58] <inflatador>	 nope, it's all good, thanks for merging!
[21:19:34] <cwhite>	 great :)
[21:20:48] <cwhite>	 inflatador: that said, I just checked puppetboard: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Invalid relationship: Package[wmf-elasticsearch-search-plugins] { require => Package[elasticsearch-oss] }, because Package[elasticsearch-oss] doesn't seem to be in the catalog
[21:21:45] <inflatador>	 cwhite ACK, ryankemper is reverting the change
[21:23:12] <cwhite>	 I think changing `elasticsearch-oss` -> `elasticsearch` will probably get you what you want.  Most other uses of require use the `elasticsearch` resource title.
[21:28:32] <inflatador>	 yeah, I think we set a var for the "correct pkg name" based on facts earlier, probably shouldn't be hardcoding it here
[21:33:23] <cwhite>	 In Puppet, package name and resource title are usually the same.  In this case, resource title is what Puppet is looking for and is different than package name.  For example, it's legal but not especially nice to do: `package { 'vim': ensure => present, name => 'emacs' }`
[21:36:05] <bd808>	 cwhite: that's an evil example :)
[21:36:08] <cwhite>	 inflatador: see: https://github.com/wikimedia/puppet/blob/production/modules/elasticsearch/manifests/packages.pp#L11
[21:39:36] <inflatador>	 yeah, it looks like we are doing it the right way in that module, package_name var set here: https://github.com/wikimedia/puppet/blob/production/modules/elasticsearch/manifests/init.pp#L34
[22:01:30] <inflatador>	 If anyone has time, can you sanity-check my first alert manager suppression? It wouldn't let me go past 24 hrs: https://alerts.wikimedia.org/?q=%40silence_id%3Dece719db-85c9-4b1c-9d79-910e598756bf
[22:05:00] <cwhite>	 inflatador: How long do you want it to last?
[22:05:11] <inflatador>	 a week
[22:06:36] <inflatador>	 Ah nice, I see you fixed it. Thanks cwhite !
[22:06:55] <cwhite>	 I recast it to expire in 7 days.  Hope that helps :)
[22:14:41] <mutante>	 hmm, no stockcarracing.wikimedia.org :p  https://phabricator.wikimedia.org/T299249
[22:24:05] <bd808>	 mutante: the weird thing about that particular task is that the user was able to auth to Phab and create it. The SUL account for that user has been global blocked since 2020-04-23
[22:45:54] <mutante>	 bd808: oh, is that because "request for wiki creation" is a form that creates the ticket for them..maybe
[22:47:13] <bd808>	 I think I convinced myself that it is because phabricator has wildly long session durations. My session cookie is good until 2025.
[22:48:25] <mutante>	 hmm.. *nod*