[09:18:30] 10netops, 10Infrastructure-Foundations, 10SRE, 10Traffic: Unable to load en.wikipedia.org from 84.19.61.192/26 - https://phabricator.wikimedia.org/T279503 (10A189605) Thanks. I'd say you can close this one down, thanks for you and your teams support. [09:21:01] 10netops, 10Infrastructure-Foundations, 10SRE, 10Traffic: Unable to load en.wikipedia.org from 84.19.61.192/26 - https://phabricator.wikimedia.org/T279503 (10ayounsi) 05Open→03Resolved a:03cmooney Great news! Out of curiosity, is it possible to know the root cause? Thanks [09:23:57] 10netops, 10Infrastructure-Foundations, 10SRE, 10Traffic: Unable to load en.wikipedia.org from 84.19.61.192/26 - https://phabricator.wikimedia.org/T279503 (10A189605) We're still not aware of the root cause, but it certainly isn't yourselves given some recent testing we've conducted. [13:28:32] hi all at the beginning of the week i created a new ldap group and unix groups for sre-admins. the idea of this group is to give some privalages to new SRE hires without having to give them full root. This group is not currently in use however it occured to me that it should have been approved by this group. [13:30:07] however i want/thinks it makes sense to add this group to the alwys_groupwhich means that sres in this new group would be able to login to all serveres but they would be missing sudo rights. would be usefull to follow along in an incident and to just look around? As this opens up more permissions i think we shuld at the very least approve it in infrastructure foundations [13:30:13] https://gerrit.wikimedia.org/r/c/operations/puppet/+/715733 [13:30:44] that change also proposes to make the same group root on the sretest serveres which also introduces a new group (sretest-roots) [13:31:31] finnaly there is a proposal to create a os-installers group to allo theses sre to run the reimage script https://gerrit.wikimedia.org/r/c/operations/puppet/+/715729/8/modules/admin/data/data.yaml from policy this should also be approved [13:31:56] so with that in mind: [13:32:14] can we retrospectivaly approve the sre-admins group [13:32:36] can we approve the sretest-roots and os-installers groups [13:32:54] can we approve the expansion of the sre-admins group as mentioned above [13:34:39] further th os-installeres change has this comment "We have a process how to add new members to existing groups " suggesting we need to comunicate better that infrastructre foundations should be apporving theses new groups (and we need to design a procedure for that, i think we suggested doing this in the monnday meeting but not sure thats happened yet) [13:34:58] jobo: please see ^^^ (i can also send this in an email if its easier) [13:35:19] (cc rzl) [13:36:41] fwiw I think sre-admins is a good idea and it's a +1 from me [13:37:24] for the os-installer one I'm not sure if we should just add the permission to the sre-admins, no strong opinion, but it should go together with a new group in pwstore to access the mgmt password, otherwise is useless [13:38:17] and +1 to make more explicit the approval process to create new groups [13:45:33] * jbond is also a +1 for all the proposals above (i have added a comment on the task about the pw store) [13:46:33] something elses to add to this is some policy around who gets full root and who goes into the sre-admins group, and share that understanding with other groups e.g. wmcs, analytics, etc [13:52:17] Thanks for that John, I think that it's sensible to have separate group for new hires. That already has one very valid use case - Wolfgang's IC4 role and all in all is a good idea for all new SREs IC6 below. As for "We have a process how to add new members to existing groups " - we did discuss it indeed on our Monday meeting. We've agreed to propose the LDAP access split between wmf vs nda basing on users having or not a wikikimedia.org [13:52:17] mail account. I will check with Mark & Faidon when they are around. Have I missed something? [13:55:58] ah and in regards to "We have a process how to add new members to existing groups ". Fully agreed, let me take care of that. I think first step would be actually to find all the documentation we have around that, from what you've said we have quite a few places? [13:57:22] opps i copypasted the wrong bit of daniles comment. the important bit was "t not really for how to create new admin groups." [13:58:16] i.e. this is not related to the nda/wmf descussion we had on monday. this is more genral, we use to have approval of new unix groups in the monday sre meeting but that got delagated to IF [14:17:42] FYI - we just had a quick call with John. All three proposed groups are approved. I'll create a wiki to start documenting policy around the process and will add it as a topic for our Monday meeting. [14:23:23] thanks :) [19:54:33] 10CAS-SSO, 10GitLab, 10Infrastructure-Foundations, 10Patch-For-Review, and 2 others: Open gitlab.wikimedia.org to all users with Wikimedia developer accounts - https://phabricator.wikimedia.org/T288162 (10brennen) [19:55:50] 10Puppet, 10GitLab, 10Infrastructure-Foundations, 10Patch-For-Review, and 3 others: Puppetise gitlab-ansible playbook - https://phabricator.wikimedia.org/T283076 (10brennen)