Requesting access to ops (or wmcs-roots) for TheresNoTime
Closed, ResolvedPublicRequest
Actions

Assigned To

Authored By

	TheresNoTime
	May 31 2023, 9:23 AM

Description

Requestor provided information and prerequisites

This section is to be completed by the individual requesting access.

Wikitech username: samtar
Email address: sam@theresnotime.co.uk
SSH public key (must be a separate key from Wikimedia cloud SSH access): ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILvhdG381YRtB7eyRf04bnH6dSYz1+6JF84mpY3yh9K0 sam@theresnotime.co.uk
Requested group membership: ops (or wmcs-roots, see below)
Reason for access:

During the recent wiki replica outage (T337446), I highlighted the need to potentially regenerate the meta_p database (via the maintain-meta_p script). I would have liked to assist the responding engineer by, if not running (as I would of course not run something I wasn't entirely confident in…), at least investigating the requisite steps further. To do either of these things, I required access to the cumin/clouddb hosts.
If granted, I would endeavour to continue to be as available as I currently am, and respond where appropriate to similar issues.
I note this comment by @Volans which mentions a wmcs-roots group — this may be more appropriate for the use case I describe.

Previous:
T302231: Requesting access to deployment for TheresNoTime
T317438: Toolforge root for TheresNoTime

Name of approving party (manager for WMF/WMDE staff): As I'm making this request with "my volunteer hat on", I believe this is @lmata ? My manager can approve if necessary, though.
Ensure you have signed the L3 Wikimedia Server Access Responsibilities document: ✅
Please coordinate obtaining a comment of approval on this task from the approving party.

SRE Clinic Duty Confirmation Checklist for Access Requests

This checklist should be used on all access requests to ensure that all steps are covered, including expansion to existing access. Please double check the step has been completed before checking it off.

This section is to be confirmed and completed by a member of the SRE team.

- User has signed the L3 Acknowledgement of Wikimedia Server Access Responsibilities Document.
- User has a valid NDA on file with WMF legal. (All WMF Staff/Contractor hiring are covered by NDA. Other users can be validated via the NDA tracking sheet)
- User has provided the following: wikitech username, email address, and full reasoning for access (including what commands and/or tasks they expect to perform)
- User has provided a public SSH key. This ssh key pair should only be used for WMF cluster access, and not shared with any other service (this includes not sharing with WMCS access, no shared keys.)

[already added] - The provided SSH key has been confirmed out of band and is verified not being used in WMCS.

- access request (or expansion) has sign off of WMF sponsor/manager (sponsor for volunteers, manager for wmf staff)
- access request (or expansion) has sign off of group approver indicated by the approval field in data.yaml

For additional details regarding access request requirements, please see https://wikitech.wikimedia.org/wiki/Requesting_shell_access

Details

	Subject	Repo	Branch	Lines +/-
	Add user samtar to shell group wmcs-roots	operations/puppet	production	+1 -1

Customize query in gerrit

Related Objects

Mentioned Here: T334041: Run maintain-views on zhwiki, newiki
T337848: WMCS-roots wiki replica access
T302231: Requesting access to deployment for TheresNoTime
T317438: Toolforge root for TheresNoTime
T337446: Rebuild sanitarium hosts

Event Timeline

TheresNoTime created this task.May 31 2023, 9:23 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 31 2023, 9:23 AM

+1 to wmcs-roots access.

The mentioned cumin access has more implications, so I'm hoping that others with more knowledge of the whole access request worklow can comment on that.

I presume resolving T337848: WMCS-roots wiki replica access would unblock the situation you described, yes? And if I'm reading correctly, your desire would be to help in WMCS spaces longer term yes? That would point to wmcs-roots as the correct level of access. Additionally, it would be helpful on an ongoing basis in understanding other situations where wmcs-roots access isn't enough to help ensure a WMCS root can manage all WMCS hosts.

MusikAnimal awarded a token.Jun 2 2023, 6:15 PM

In T337829#8893753, @nskaggs wrote:

I presume resolving T337848: WMCS-roots wiki replica access would unblock the situation you described, yes? And if I'm reading correctly, your desire would be to help in WMCS spaces longer term yes? That would point to wmcs-roots as the correct level of access. Additionally, it would be helpful on an ongoing basis in understanding other situations where wmcs-roots access isn't enough to help ensure a WMCS root can manage all WMCS hosts.

Yup, agree that wmcs-roots looks like the correct level of access — will wait on T337848: WMCS-roots wiki replica access to be resolved :-) (there is no rush from my side!)

It would be great to have someone with this access on our team (Community-Tech). I.e., recently I waited over a month for T334041: Run maintain-views on zhwiki, newiki to be processed.

From experience: wmcs-roots is basically useless for wiki replica work. If T337848: WMCS-roots wiki replica access ends up expanding access for that group to wiki replica cookbooks and the replica hosts themselves, there are still several parts that need would need ops access, like (de)pooling the replica servers for any user-affecting maintenance and doing any changes to the maintain-views configuration.

RhinosF1 subscribed.Jun 5 2023, 8:44 PM

@nskaggs you're the listed approver for the wmcs-roots group, are you OK to approve access to that?
@lmata are you happy to approve the request from this volunteer account? [they are also a current WMF staff member, I don't know how/if that changes approval]

cmooney claimed this task.Jun 6 2023, 10:15 AM

cmooney triaged this task as Medium priority.

Yes, approved for wmcs-roots.

In T337829#8899615, @taavi wrote:

From experience: wmcs-roots is basically useless for wiki replica work.

This matches my experience and needs to change. I want to help fix this.

If T337848: WMCS-roots wiki replica access ends up expanding access for that group to wiki replica cookbooks and the replica hosts themselves, there are still several parts that need would need ops access, like (de)pooling the replica servers for any user-affecting maintenance and doing any changes to the maintain-views configuration.

The maintain-views specifically is something I'd like to ensure wmcs-roots can do; and in general, enable more interested and capable folks to do. The de-pooling issue is something I ran into myself, and would like to see solved. I'm not sure if cloud-cumin host will help with this, or if more flexible cookbook automation is needed. Perhaps just enabling more sudo command access on specific hosts? This likely needs it's own task to discuss potential resolutions.

cmooney updated the task description. (Show Details)Jun 7 2023, 3:00 PM

MatthewVernon moved this task from Untriaged to Manager/NDA Approval/Confirmation on the SRE-Access-Requests board.Jun 8 2023, 1:13 PM

hashar unsubscribed.Jun 8 2023, 2:10 PM

In T337829#8905433, @MatthewVernon wrote:

@nskaggs you're the listed approver for the wmcs-roots group, are you OK to approve access to that?
@lmata are you happy to approve the request from this volunteer account? [they are also a current WMF staff member, I don't know how/if that changes approval]

Yes, approved for wmcs-roots.

Change 929726 had a related patch set uploaded (by Cathal Mooney; author: Cathal Mooney):

[operations/puppet@production] Add user samtar to shell group wmcs-roots

https://gerrit.wikimedia.org/r/929726

gerritbot added a project: Patch-For-Review.Jun 13 2023, 2:59 PM