- User-brennen is my personal workboard
- brennen-scratchpad is an Etherpad for miscellaneous notes
- I work on the Wikimedia Release Engineering Team
- Release-Engineering-Team is our team workboard
- RelEngTeam-Weekly (etherpad)
- Weekly sync with SRE (etherpad)
- Projects I work on:
User Details
- User Since
- Feb 3 2019, 8:29 PM (272 w, 6 d)
- Roles
- Administrator
- Availability
- Available
- IRC Nick
- brennen
- LDAP User
- Brennen Bearnes
- MediaWiki User
- BBearnes (WMF) [ Global Accounts ]
Yesterday
Thu, Apr 25
Stable on all wikis since deploy. Optimistically resolving.
Wed, Apr 24
Tue, Apr 23
Also resulting in:
Note that I'll probably be a sub-optimal backup here after mid-day on Wednesday - traveling to Hackathon that afternoon.
Thu, Apr 18
Also noting after some slack discussion with @bd808 that !7101: Support loading of locally installed gems remains open, but seems probably stalled out.
I guess my other thought about a home for this is that it could live in gitlab-settings/configure-projects - a script which really does very little, and could be a lot smarter about what it does do, but does already iterate over projects and change some settings.
Tue, Apr 16
Prepping a revert.
Mon, Apr 15
We'll deploy @Aklapper's patch above tomorrow, 2024-04-16.
Will deploy tomorrow, 2024-04-16.
Will deploy https://gitlab.wikimedia.org/repos/phabricator/phabricator/-/merge_requests/37 tomorrow 2024-04-16.
Seems like a good idea to me. Tweaked the MR slightly after testing.
Should deploy tomorrow, 2024-04-16.
May be lingering documentation cleanup here after script deletion.
Will deploy tomorrow, 2024-04-16.
Applied delete from the merge request at:
Also, just so i'm clear... your new puppet7 server is still named 'puppetmaster<something>' rather than 'puppetserver<something'>, is that right? (In all other projects the new servers don't use the 'puppetmaster' name so I can tell the difference between new and old).
Thu, Apr 11
I changed puppetmaster-1003 to role::puppetserver::cloud_vps_project, and puppet runs now seem to be working there. @Dzahn is updating other boxen in the project to use the new puppetmaster. We'll consider this one resolved.
Although currently undocumented, it looks like it's require_admin_two_factor_authentication in the API, based on:
No objections here. In practice all current admins are probably already required to use 2fa due to membership in one or more groups that require it, but there's no harm in enabling the setting.
Wed, Apr 10
Yeah, I'm sure it could be improved.
Thu, Apr 4
Also noting after some slack discussion with @bd808 that !7101: Support loading of locally installed gems remains open, but seems probably stalled out.
The upstream integration has merged, so hopefully that'll be available in a release before long. Marking this as stalled until we can use it.
Wed, Apr 3
Tue, Apr 2
Mon, Apr 1
This task is hanging out from a sprint ~2 years ago. Seems like it served its purpose at the time.
Relevant docs can now be found under https://wikitech.wikimedia.org/wiki/GitLab/Gitlab_Runner
I now think our original framing of this was somewhat optimistic.
That really seems like a use case for the IDM to fulfill rather than trying to use the opaque internals of GitLab to store correlated data that as you say we would like to reuse for other workflows.
Thu, Mar 28
That did the trick. Second run:
Yeah, it looks like /srv/git/operations/puppet was checked out to an old testing branch from Gerrit. That's now fixed, although it doesn't have any effect on the error on phabricator-bullseye.
I configured a new puppetmaster-1003 through to step 7 above.
Mar 28 2024
This seems to have traction and is currently in a 3rd round of review.
Mar 26 2024
I suspect we have an explanation here:
Mar 25 2024
All listed users invited as owners.