[13:07:38] Hi all! we got a newcommer, and they created a new task to get global root, (https://phabricator.wikimedia.org/T313504), am I (sre member, but same team) allowed to review and approve it? or should someone else go through it? [13:10:48] dcaro: If you're requesting the same level of access as the rest of your team already has (e.g. because you've joined the team and you're requesting to be added to the group) then no further approval is necessary; your manager's on-ticket approval (or for non-staff, your WMDE's manager or WMF sponsor's on-ticket approval) is sufficient. [13:10:53] dcaro: Usually it requires manager [13:11:09] dcaro: also fwiw, there is https://office.wikimedia.org/wiki/SRE/Training_Checklists#Goal:_Root_access [13:11:21] up to you but at least for the Traffic team's new hire, we made sure they went through this process [13:11:34] rzl can comment better but I also think it is mandatory (?) now? [13:12:27] sukhe: it probably should be added to https://wikitech.wikimedia.org/wiki/SRE/Production_access#Eligibility if it is [13:12:36] RhinosF1: good point [13:12:41] for the eventual approval: for each group (here "ops"), there's an approval: in modules/admin/data/data.yaml, since Nicholas is listed there, he can approve the access whenever he thinks your new hire is ready for global root access [13:12:44] so let's wait to see if it is actually mandatory or just a suggestion [13:15:43] thanks! (I'll wait for manager approval of course) [13:16:34] that readiness checklist is very useful btw. though the oncall on WMCS is different (different rotation), and cookbooks is also a bit different [13:26:07] yeah that's also a good question I think. should it not apply to WMCS because things are different or it should apply because even if they are, global root is still involved [13:26:33] to be clear, I have no skin in the game other than ensuring that we apply it fairly to everyone -- that is to all newcomers -- or make it clear that it's optional :) [13:26:48] so in that regard, sorry for using your existing question to stir up this! [13:26:59] I'm ok with that too, just wondering how to proceed xd [13:29:25] I think waiting for rzl is a good idea to get more clarity since he worked on the document above and the procedures and knows the most about it, I think [13:29:34] (it's early in his timezone :) [13:29:36] 👍 good for me :) [14:23:10] sukhe, dcaro: thanks for checking! it's expected for all SREs in the core team (everyone under Mark and Faidon except dcops) but not for teams like WMCS -- applying the same format might eventually be a good idea, but we'd want to adapt the content, and I don't think it's been discussed with management on that side at all at this stage [14:38:46] thanks for confirming rzl! [14:38:54] thanks! [15:04:20] paravoid: question_mark: am I on the hook for the topic presentation at the upcoming SRE Monday meeting? just want to plan my next two days [15:05:49] i don't think we have another topic, so if it fits your schedule it would be good [15:05:58] but also don't want to put anything else under pressure unnecessarily [15:05:59] it will be a bit informal but I think that's okay [15:06:04] yeah [21:28:17] when you use disable-puppet 'message' via cumin on a lot of hosts, I know how to disable and enable all that match the message but can I also get a list of "hosts currently still disabled with this message" [21:30:06] was looking at puppetboard.wikimedia.org for a "disabled" nodes column at first [21:32:20] mutante: you can run with cumin 'source /usr/local/share/bash/puppet-common.sh && cat $PUPPET_DISABLEDLOCK' [21:32:38] the file doesn't exist if puppet is enabled and has the message if disabled [21:32:42] like: [21:32:43] {"disabled_message":"test - volans"} [21:33:04] volans: :) cool, thank you [21:33:24] Salam [21:34:03] Haker tu Pe free fri contest [21:34:20] Coco [21:44:21] I ended up using "file /var/lib/puppet/state/agent_disabled.lock" and that wfm