[07:01:00] <jelto>	 Gerrit needs a short restart in around one hour
[08:03:19] <dcaro>	 volans: I'm on linux :}, I'm testing it again this morning, and it seems to be working 🤞, will do more tests before removing the old keys
[08:07:50] <jelto>	 Gerrit reboot happening now
[08:16:27] <jelto>	 Gerrit should be back
[08:19:05] <_joe_>	 not really
[08:19:11] <_joe_>	 fatal: unable to access 'https://gerrit.wikimedia.org/r/p/operations/puppet.git/': Recv failure: Connection reset by peer
[08:19:58] <_joe_>	 it's possible the http clone url has changed?
[08:20:11] <_joe_>	 works now
[08:22:13] <jelto>	 oh that's surprising. Cloning the puppet repo here works fine again too
[08:31:07] <_joe_>	 the url *has* changed btw but there's an automatic redirect at least
[08:34:00] <jelto>	 but that's most likely unrelated to the maintenance reboot. That was just a kernel update
[09:11:28] <vgutierrez>	 I just seen Info: Applying configuration version '(462263005c) Klausman - chore: add dpogorzelski to ops-limited'
[09:11:40] <vgutierrez>	 please don't forget to follow the commit message conventions of the puppet repo
[09:11:48] <klausman>	 ack
[09:12:12] <klausman>	 (I only merged it, didn't write the commit msg, but will relay)
[09:12:37] <taavi>	 shoudln't that change have had a corresponding sre-access-requests ticket?
[09:12:45] <vgutierrez>	 that too :(
[09:14:59] <klausman>	 Dangit, I'll investigate
[09:15:43] <vgutierrez>	 actually.... I'm gonna revert that one
[09:15:47] <vgutierrez>	 I can't find a task
[09:17:41] <klausman>	 yeah, the checklist we used conveniently skips over needing a ticket
[09:17:45] <taavi>	 +1
[09:17:56] <vgutierrez>	 klausman: the approval for that group mentions question_mark 
[09:18:01] <vgutierrez>	 where is his approval?
[09:18:35] <klausman>	 https://office.wikimedia.org/wiki/Technology/Onboarding/Checklists/Dawid_Pogorzelski#Site_Reliability_Engineering
[09:18:49] <dpogorzelski>	 sorry if i missed some steps and the confusion :) 
[09:18:51] <klausman>	 In this checklist, there is no mention of a ticket/approcal needed
[09:19:58] <vgutierrez>	 klausman: approvals are defined on data.yaml itself
[09:20:20] <dpogorzelski>	 regarding "please don't forget to follow the commit message conventions of the puppet repo" where can i find information about that?
[09:20:36] <klausman>	 https://gerrit.wikimedia.org/r/c/operations/puppet/+/1197978 is the group change, and it depends on the user change
[09:20:42] <taavi>	 dpogorzelski: https://www.mediawiki.org/wiki/Gerrit/Commit_message_guidelines
[09:23:03] <dpogorzelski>	 👍
[09:23:50] <dpogorzelski>	 if there is a template for the onboarding guide i could update it with the extra info
[09:24:00] <vgutierrez>	 I've reverted the ops-limited CR, please seek approval and I'll be happy to approve/merge that
[09:24:12] <vgutierrez>	 sorry for all the fuzz dpogorzelski :)
[09:24:32] <klausman>	 It's on me, really. I should have remembered the access ticket requirement
[09:24:54] <taavi>	 tbh we should make the CI enforce a referenced ticket when changing access
[09:25:53] <dpogorzelski>	 👍
[09:26:14] <klausman>	 We'll follow https://wikitech.wikimedia.org/wiki/SRE/Production_access#Access_Request_Process now
[09:26:24] <vgutierrez>	 thx <3
[09:36:23] <marostegui>	 phabricator down?
[09:36:48] <jelto>	 not for me no
[09:37:28] <jelto>	 also phab metrics look quite normal to me
[09:37:54] <vgutierrez>	 working here
[09:38:20] <Emperor>	 aol
[09:38:23] <marostegui>	 Seems to be back yep
[09:38:25] <marostegui>	 THank you all
[11:05:01] <jelto>	 GitLab needs a short maintenance break in one hour (12:00 UTC)
[12:13:10] <jelto>	 GitLab maintenance done
[14:04:40] <andrewbogott>	 I'm running into partman issues with a config B 4-drive host and could really use a second server to see if I can reproduce there. Does anyone have an insetup Dell server with 4 drives I can use as a lab rat?
[15:20:26] <dpogorzelski>	 should the access request be assigned to someone in specific or it will be picked up by someone from the project?
[15:23:28] <taavi>	 the sre clinic duty person will deal with that, as explained on the #sre-access-requests project description
[15:54:02] <_joe_>	 dpogorzelski: hey welcome aboard!
[16:01:11] <jynus>	 by any chance, does anyone have any vm with a spare/unused host with nftables ?
[16:01:21] <jynus>	 I would like to do some production testing
[16:04:29] <jynus>	 alternativelly, I could ask for a temporary vm just for testing and remove it afterwards
[16:04:40] <mutante>	 jynus: just some commands that dont change stuff permanently? you can use zuul2002.codfw.wmnet 
[16:04:54] <mutante>	 trixie with nft
[16:05:13] <mutante>	 monitoring is downtimed. hf
[16:05:14] <jynus>	 I will be just moving fake empty files around, but I would prefer it wasn't in use
[16:05:28] <mutante>	 not in use
[16:05:32] <jynus>	 ah
[16:05:35] <jynus>	 thanks then
[16:05:51] <mutante>	 yep.np
[16:06:17] <jynus>	 I will give a ping here when I start using it (I intend to just write some files to $home and then delete them)
[16:06:24] <jynus>	 and when I stop using it too
[16:06:38] <mutante>	 sounds good!
[16:07:21] <jynus>	 thank you a lot
[16:51:28] <andrewbogott>	 During reimage, I would like the debian installer to pause right before the reboot so I can see what it looks like before the (destined to fail) reboot. Is there any good way to do that?
[17:14:24] <dpogorzelski>	 _joe_: thanks :) 
[17:16:22] <jynus>	 mutante: sadly zuul2002 won't work for me, as it is still upsing iptables
[17:22:03] <jhathaway>	 andrewbogott: if I recall correctly, you can disable puppet on apt1002, comment out the two reboot_in_progress config options, then run your install
[17:22:14] <mutante>	 jynus: ah, right! that's because of docker. I only checked if nft is installed. but dont worry.. I am changing that right now
[17:25:18] <andrewbogott>	 jhathaway: huh, presumably that will mess with anyone else who is also reimaging...
[17:26:10] <andrewbogott>	 But if I wait a few hours that will be noone
[17:43:51] <jhathaway>	 andrewbogott: true, but with a little communication, it is usually okay
[18:07:56] <mutante>	 jynus: I made some changes. zuul2002 uses nft now and has insetup role
[18:08:36] <jynus>	 no worries, I think I will use another host, but thanks for offering
[18:09:06] <mutante>	 is there a reason left to use another host now?
[18:09:13] <mutante>	 I just did that so you can use it 
[18:09:30] <jynus>	 not really, just I didn't want to bother you with this
[18:09:56] <jynus>	 I don't want to put the burden on you
[18:10:10] <mutante>	 it's already done
[18:10:17] <jynus>	 in any case, I am finishing my day
[18:10:21] <jynus>	 so no more testing for now
[18:10:23] <mutante>	 not using it means only reverting
[18:10:35] <jynus>	 then let me use it tomorrow
[18:10:46] <jynus>	 I just didn't want to make you work more
[18:11:02] <jynus>	 0:-)
[18:11:11] <mutante>	 alright. use it tomorrow. enjoy the rest of the day. laters
[19:30:33] <andrewbogott>	 jhathaway: now that I'm following up... I don't understand what you mean by 'the two reboot_in_progress config options'. Where would those be?  And is it really on the apt server and not on install100x ?
[19:31:14] <jhathaway>	 andrewbogott: grep reboot /srv/autoinstall/common.cfg
[19:31:20] <jhathaway>	 those two ^
[19:31:29] <andrewbogott>	 thx
[19:31:30] <jhathaway>	 on apt1002
[19:31:43] <jhathaway>	 if that doesn't work, I can try to find my notes and reproduce
[19:31:51] <andrewbogott>	 ok! trying...
[19:48:03] <jhathaway>	 debug an issue, search on google for debian bug report, find bug report, read reply that Morit.z asked about this issue on IRC in **2017**, 🤦, at least I didn't fine my own bug report, which has happened to me before.
[19:48:44] <andrewbogott>	 the install pause is working!
[19:49:11] <jhathaway>	 andrewbogott: great!