[00:00:11] thcipriani: I'd like to switch the primary deployment server to deploy2002 (in codfw) sometime the week of July 12th, and was hoping to have someone from releng around in case we run into scap issues [00:02:33] legoktm: that sounds possible. either dancy or twentyafter.four (who's out this week) would probably be likely candidates for folks that could help with the deployment server switchover. Are you worried about anything in particular? Or is this a "on hand to diagnose problems" kinda request? [00:03:11] the latter mostly [00:04:16] https://wikitech.wikimedia.org/wiki/Switch_Datacenter/DeploymentServer seems rather straightforward but I'm just a bit skeptical with all the various deployment automation changes we've been making lately [00:04:54] got it. In that case, as long as you do the switchover during US daytime hours, there should be plenty of relengers on-hand. [00:05:37] great, I'll file a task in a bit [00:06:03] <3 [00:07:24] 10Gerrit, 10Mobile: Can't type slash character ("/") in Gerrit web editor - https://phabricator.wikimedia.org/T282387 (10Paladox) Backported the change here: https://gerrit-review.googlesource.com/c/gerrit/+/310683 [00:09:51] 10Gerrit, 10Mobile, 10Upstream: Can't type slash character ("/") in Gerrit web editor - https://phabricator.wikimedia.org/T282387 (10Paladox) [00:16:16] 10Gerrit: gerrit's sshd is incompatible with RSA pubkeys + Fedora 33 clients (and future versions of OpenSSH proper) - https://phabricator.wikimedia.org/T276486 (10Paladox) Seems this is now fixed https://issues.apache.org/jira/browse/SSHD-1141?focusedCommentId=17317087&page=com.atlassian.jira.plugin.system.issu... [00:44:19] 10Release-Engineering-Team, 10serviceops, 10Datacenter-Switchover: Switch deployment server to codfw (July 2021) - https://phabricator.wikimedia.org/T285820 (10Legoktm) [00:45:24] 10Release-Engineering-Team, 10serviceops, 10Datacenter-Switchover: Switch deployment server to codfw (July 2021) - https://phabricator.wikimedia.org/T285820 (10Legoktm) [01:04:03] 10Gerrit, 10Upstream: Editing via the web interface, "Drag and drop a file here" does not accept files in "Add a new file or open an existing file" - https://phabricator.wikimedia.org/T274699 (10Paladox) Fixed with https://gerrit-review.googlesource.com/c/gerrit/+/310664 [06:37:39] can a phab admin delete https://phabricator.wikimedia.org/T46353#7185958, thanks [07:03:32] 10Continuous-Integration-Config, 10Wikidata, 10Wikidata-Campsite, 10wdwb-tech: Run CI tests daily on master for ungated extensions - https://phabricator.wikimedia.org/T285049 (10Addshore) [07:09:56] 10Release-Engineering-Team (Radar), 10Prod-Kubernetes, 10serviceops, 10Kubernetes: CI pipeline/job to build and release helm chart artifacts - https://phabricator.wikimedia.org/T257333 (10JMeybohm) >>! In T257333#7184596, @thcipriani wrote: > Is this task superseded by the cronjob on the deployment machine... [07:10:51] (03CR) 10Hashar: [C: 03+2] Revert "Restore generic-node10-docker" [integration/config] - 10https://gerrit.wikimedia.org/r/699563 (owner: 10Jforrester) [07:11:21] (03CR) 10Hashar: [C: 03+2] "Got restored for node-rdkafka-statsd but that is no more needed indeed." [integration/config] - 10https://gerrit.wikimedia.org/r/699563 (owner: 10Jforrester) [07:12:13] (03Merged) 10jenkins-bot: Revert "Restore generic-node10-docker" [integration/config] - 10https://gerrit.wikimedia.org/r/699563 (owner: 10Jforrester) [07:54:15] 10Release-Engineering-Team (Doing), 10Scap, 10WMDE-TechWish-Sprint-2021-06-23: Python3 scap breaks mediawiki - https://phabricator.wikimedia.org/T285345 (10hashar) @dduvall that is an excellent patch and I definitely love the round trip write/read test :-] [08:55:02] 10Release-Engineering-Team (Doing), 10Scap, 10SRE, 10Python3-Porting: Porting scap to Python 3 - https://phabricator.wikimedia.org/T279628 (10Jdforrester-WMF) [08:55:09] 10Release-Engineering-Team (Doing), 10Scap, 10WMDE-TechWish-Sprint-2021-06-23: Python3 scap breaks mediawiki - https://phabricator.wikimedia.org/T285345 (10Jdforrester-WMF) 05Open→03Resolved a:05dduvall→03dancy [10:46:15] 10Continuous-Integration-Config, 10Wikidata, 10Wikidata-Campsite, 10wdwb-tech: Run CI tests daily on master for ungated extensions - https://phabricator.wikimedia.org/T285049 (10Addshore) [10:55:39] 10Continuous-Integration-Config, 10Wikidata, 10wdwb-tech, 10Wikidata-Campsite (Wikidata-Campsite-Iteration-∞): Run CI tests daily on master for ungated extensions - https://phabricator.wikimedia.org/T285049 (10Addshore) [11:02:44] where is the right place to discuss phab things? are there docs for the project reports like https://phabricator.wikimedia.org/project/reports/3532/ ? [11:19:06] addshore: Here, I suppose. Not sure about docs, sorry. [11:20:29] Given upstream's demise, the prototype probably won't become an official thing. [11:20:54] Hi! [11:21:17] A new build of blubber really should be deployed at https://releases.wikimedia.org/blubber/ [11:22:21] Came across this when attempting to build images that due to legacy use python2.7, as the currently deployed binary of blubber isn't aware of pip21 not supporting python2.7. [11:22:36] https://gerrit.wikimedia.org/g/blubber/+/459234d2acb785a0831e12f653a72df3e3c34272/config/python.go#198 [11:22:50] The current 0.8.0 blubber deployed is from 2019... [11:23:15] Should I create a task in Phabricator in the rel-eng-board? [11:23:25] https://phabricator.wikimedia.org/project/view/2812/ [11:27:44] James_F: indeed [11:27:55] kalle_: Yes, a new task on https://phabricator.wikimedia.org/project/board/20/ would be good. [11:28:17] James_F: I might just make https://grafana.wikimedia.org/d/000000172/wikidata-tasks?orgId=1&refresh=30m for this other board I am intersted in then :P [11:28:34] addshore: Oh gods. [11:28:47] addshore: Phab and Grafana, together at last! WCPGW?! [11:30:00] kalle_: Though FWICS from https://gerrit.wikimedia.org/r/plugins/gitiles/blubber/+refs the latest tag is 0.6.0 from 2018? [11:31:20] James_F: WCPGW, well, it screen scrapes, and upstream is no longer owned by anyone, so, nothing ig uess? :P [11:31:34] addshore: Aka "everything". [11:32:17] Last image tagged for blubber in our docker-registry is 2021-04-21-203405-production per https://docker-registry.wikimedia.org/wikimedia/blubber/tags/ but it'd need someone to manually trigger a roll-out. [11:32:32] Not sure how to work out which image is actually running. [11:35:29] 10Release-Engineering-Team (Seen), 10MW-on-K8s, 10serviceops, 10Release Pipeline (Blubber): Blubber needs to check if a user is present before creating it as part of its runs stanza - https://phabricator.wikimedia.org/T268819 (10Jdforrester-WMF) Is this done? Does the new image need to be deployed to blubb... [11:56:38] 10Release-Engineering-Team: Release new binary of blubber - https://phabricator.wikimedia.org/T285853 (10kalle) [11:57:14] 10Release-Engineering-Team: Release new binary of blubber - https://phabricator.wikimedia.org/T285853 (10kalle) [11:58:38] James_F: https://phabricator.wikimedia.org/T285853 [12:01:32] Thanks. Subscribed, though I think in practice everyone is expected to use blubberoid nowadays. [12:08:43] James_F: I do blubber manually on my laptop when blubberizing the projects for the first time. [12:09:23] But blubberiod have the same timestamp at https://releases.wikimedia.org/blubber/0.8.0/linux-amd64/ [12:09:39] it has.. grammar... [12:16:58] I forget... what do I have to do in order to have libpipeline execute on my new repo? [12:17:12] https://gerrit.wikimedia.org/r/c/mediawiki/services/wikispeech/ahotts/+/702345 [12:18:03] Need to edit some funky file in some other repo [12:27:17] can a phab admin delete https://phabricator.wikimedia.org/T46353#7185958, thanks [12:28:46] kalle_: You mean, the CI config repo? integration/config.git. [12:30:50] (03PS4) 10Jforrester: Zuul: [mediawiki/core] Drop PHP70/71 testing for REL1_31 [integration/config] - 10https://gerrit.wikimedia.org/r/683779 [12:31:03] Reedy: Want to C+1 ^? [12:32:13] (03PS5) 10Jforrester: jjb: [quibble] Drop PHP70 and PHP71 testing [integration/config] - 10https://gerrit.wikimedia.org/r/683032 [12:32:35] (03PS4) 10Jforrester: dockerfiles: Drop quibble-stretch-php7{0,1}, unused [integration/config] - 10https://gerrit.wikimedia.org/r/683780 [12:32:57] (03CR) 10Reedy: [C: 03+1] Zuul: [mediawiki/core] Drop PHP70/71 testing for REL1_31 [integration/config] - 10https://gerrit.wikimedia.org/r/683779 (owner: 10Jforrester) [12:34:01] (03CR) 10Jforrester: [C: 03+2] Zuul: [mediawiki/core] Drop PHP70/71 testing for REL1_31 [integration/config] - 10https://gerrit.wikimedia.org/r/683779 (owner: 10Jforrester) [12:35:00] (03Merged) 10jenkins-bot: Zuul: [mediawiki/core] Drop PHP70/71 testing for REL1_31 [integration/config] - 10https://gerrit.wikimedia.org/r/683779 (owner: 10Jforrester) [12:36:46] !log Zuul: [mediawiki/core] Drop PHP70/71 testing for REL1_31 [12:36:48] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [12:37:20] James_F: Indeed, thanks! [12:40:17] (03PS1) 10Karl Wettin (WMSE): Add wikispeech-ahotts to ci pipeline [integration/config] - 10https://gerrit.wikimedia.org/r/702357 (https://phabricator.wikimedia.org/T285840) [12:52:05] (03CR) 10Jforrester: [C: 03+2] Add some wrappers for JJB [integration/config] - 10https://gerrit.wikimedia.org/r/693431 (owner: 10Hashar) [12:53:05] (03Merged) 10jenkins-bot: Add some wrappers for JJB [integration/config] - 10https://gerrit.wikimedia.org/r/693431 (owner: 10Hashar) [13:17:41] (03PS6) 10Jforrester: jjb: [quibble] Drop PHP70 and PHP71 testing [integration/config] - 10https://gerrit.wikimedia.org/r/683032 [13:18:44] (03CR) 10Jforrester: [C: 03+2] "Deployed." [integration/config] - 10https://gerrit.wikimedia.org/r/683032 (owner: 10Jforrester) [13:21:19] (03Merged) 10jenkins-bot: jjb: [quibble] Drop PHP70 and PHP71 testing [integration/config] - 10https://gerrit.wikimedia.org/r/683032 (owner: 10Jforrester) [13:21:41] (03PS5) 10Jforrester: dockerfiles: Drop quibble-stretch-php7{0,1}, unused [integration/config] - 10https://gerrit.wikimedia.org/r/683780 [13:29:18] (03PS1) 10Jforrester: dockerfiles: [php-ast] Stop creating modules for PHP 7.0 & 7.1, no longer needed [integration/config] - 10https://gerrit.wikimedia.org/r/702369 [13:29:33] (03CR) 10Jforrester: [C: 03+2] dockerfiles: Drop quibble-stretch-php7{0,1}, unused [integration/config] - 10https://gerrit.wikimedia.org/r/683780 (owner: 10Jforrester) [13:31:58] (03Merged) 10jenkins-bot: dockerfiles: Drop quibble-stretch-php7{0,1}, unused [integration/config] - 10https://gerrit.wikimedia.org/r/683780 (owner: 10Jforrester) [14:01:25] (03PS1) 10Jforrester: README: Organise this by theme and add more instructions [integration/config] - 10https://gerrit.wikimedia.org/r/702375 [14:05:54] (03PS3) 10Jforrester: Zuul: Drop CI support for REL1_31 branch [integration/config] - 10https://gerrit.wikimedia.org/r/683031 (https://phabricator.wikimedia.org/T281294) [14:05:56] (03PS2) 10Jforrester: jjb: [mediawiki-quibble*] Drop REL1_31 support [integration/config] - 10https://gerrit.wikimedia.org/r/683751 [14:05:58] (03PS2) 10Jforrester: jjb: [quibble] Update assert-no-errors to drop REL1_31 skip [integration/config] - 10https://gerrit.wikimedia.org/r/683752 [14:06:00] (03PS3) 10Jforrester: [DNM] dockerfiles: [composer-scratch] Upgrade to 2.0.13 and cascade [integration/config] - 10https://gerrit.wikimedia.org/r/683030 (https://phabricator.wikimedia.org/T279857) [14:06:14] (03CR) 10Jforrester: [C: 03+2] README: Organise this by theme and add more instructions [integration/config] - 10https://gerrit.wikimedia.org/r/702375 (owner: 10Jforrester) [14:07:36] (03Merged) 10jenkins-bot: README: Organise this by theme and add more instructions [integration/config] - 10https://gerrit.wikimedia.org/r/702375 (owner: 10Jforrester) [14:53:56] 10Gerrit, 10Upstream: Editing via the web interface, "Drag and drop a file here" does not accept files in "Add a new file or open an existing file" - https://phabricator.wikimedia.org/T274699 (10hashar) a:03Paladox Thank you Paladox :-] [14:54:06] 10Release-Engineering-Team, 10MW-on-K8s, 10User-brennen: TrainBranchBot merges code to mediawiki-config master branch, causing undeployed code problem - https://phabricator.wikimedia.org/T285819 (10brennen) a:03dancy [14:54:31] 10Release-Engineering-Team (Doing), 10MW-on-K8s, 10User-brennen: TrainBranchBot merges code to mediawiki-config master branch, causing undeployed code problem - https://phabricator.wikimedia.org/T285819 (10brennen) [14:55:20] 10Gerrit, 10Mobile, 10Upstream: Can't type slash character ("/") in Gerrit web editor - https://phabricator.wikimedia.org/T282387 (10hashar) a:03Paladox [14:56:10] 10Release-Engineering-Team, 10serviceops, 10Datacenter-Switchover: Switch deployment server to codfw (July 2021) - https://phabricator.wikimedia.org/T285820 (10brennen) Offhand, I think that's likely to be fine, but cc @thcipriani for awareness around train planning. (And adding to the team etherpad.) [14:56:25] 10Release-Engineering-Team (Radar), 10serviceops, 10Datacenter-Switchover: Switch deployment server to codfw (July 2021) - https://phabricator.wikimedia.org/T285820 (10brennen) [14:56:36] 10Gerrit, 10Mobile, 10Upstream: Gerrit: issues with Responsive Web Design for mobile view - https://phabricator.wikimedia.org/T256547 (10hashar) a:03Paladox [14:57:45] 10Release-Engineering-Team (Doing), 10Scap, 10WMDE-TechWish-Sprint-2021-06-23: Python3 scap breaks mediawiki - https://phabricator.wikimedia.org/T285345 (10dduvall) >>! In T285345#7186175, @hashar wrote: > @dduvall that is an excellent patch and I definitely love the round trip write/read test :-] @dancy pa... [15:05:52] 10Release-Engineering-Team (Doing), 10Release, 10Train Deployments: 1.37.0-wmf.14 deployment blockers - https://phabricator.wikimedia.org/T281155 (10brennen) Note T285820: Deployment server is likely to be switched to deploy2002 prior to train on 2021-07-14. [15:06:42] 10Release-Engineering-Team (Doing), 10Release, 10Train Deployments, 10User-brennen: 1.37.0-wmf.12 deployment blockers - https://phabricator.wikimedia.org/T281153 (10brennen) [15:27:02] 10Release-Engineering-Team (Doing), 10MW-on-K8s, 10User-brennen: TrainBranchBot merges code to mediawiki-config master branch, causing undeployed code problem - https://phabricator.wikimedia.org/T285819 (10dancy) Sorry for the confusion this caused. I have disabled the Jenkins job which updates train-versio... [15:27:12] 10Release-Engineering-Team (Doing), 10MW-on-K8s, 10User-brennen: TrainBranchBot merges code to mediawiki-config master branch, causing undeployed code problem - https://phabricator.wikimedia.org/T285819 (10dancy) p:05Unbreak!→03Medium [15:30:59] 10Release-Engineering-Team (Radar), 10serviceops, 10Datacenter-Switchover: Switch deployment server to codfw (July 2021) - https://phabricator.wikimedia.org/T285820 (10thcipriani) >>! In T285820#7187345, @brennen wrote: > Offhand, I think that's likely to be fine, but cc @thcipriani for awareness around trai... [15:35:01] 10Release-Engineering-Team (Doing), 10MW-on-K8s, 10User-brennen: TrainBranchBot merges code to mediawiki-config master branch, causing undeployed code problem - https://phabricator.wikimedia.org/T285819 (10dancy) 05Open→03Resolved TrainBranchBot has been readded to the wmf-deployment group in Gerrit. Cl... [15:37:52] 10Release-Engineering-Team (Seen), 10MW-on-K8s, 10serviceops, 10Release Pipeline (Blubber): Blubber needs to check if a user is present before creating it as part of its runs stanza - https://phabricator.wikimedia.org/T268819 (10dancy) 05Open→03Resolved >>! In T268819#7186716, @Jdforrester-WMF wrote: >... [15:47:23] 10Release-Engineering-Team (Radar), 10serviceops, 10Datacenter-Switchover: Switch deployment server to codfw (July 2021) - https://phabricator.wikimedia.org/T285820 (10Legoktm) >>! In T285820#7187576, @thcipriani wrote: > For clarity, @Legoktm should we halt deployments for this switchover? No one should be... [16:22:15] 10Project-Admins, 10TechCom-RFC, 10tech-decision-forum: Archive #TechCom-RFC project tag - https://phabricator.wikimedia.org/T284933 (10kchapman) Yes that is right @Aklapper that is accurate. [17:05:28] 10Project-Admins, 10tech-decision-forum: Archive #TechCom-RFC project tag - https://phabricator.wikimedia.org/T284933 (10Aklapper) Thanks! Archived both, plus also archived #techcom at https://phabricator.wikimedia.org/project/profile/90/ That led to [five open tasks](https://phabricator.wikimedia.org/maniphe... [17:54:35] !log restart releases-jenkins following upgrade [17:54:37] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [17:57:39] !log restart ci jenkins following upgrade [17:57:41] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [18:27:11] 10Release-Engineering-Team (Logspam), 10Math, 10Wikimedia-production-error: MathRestbaseInterface.php: TeX input is invalid. - https://phabricator.wikimedia.org/T163155 (10dduvall) Still appearing in our logs for 1.37.0-wmf.12 (cc T281153). [18:27:15] 10Release-Engineering-Team (Logspam), 10Math, 10Wikimedia-production-error: MathRestbaseInterface.php: TeX input is invalid. - https://phabricator.wikimedia.org/T163155 (10dduvall) [19:12:50] (03PS1) 10Ahmon Dancy: WIP: Initial Makefile with 'test' target [tools/scap] - 10https://gerrit.wikimedia.org/r/702445 [19:24:14] (03PS2) 10Ahmon Dancy: WIP: Initial Makefile with 'test' target [tools/scap] - 10https://gerrit.wikimedia.org/r/702445 [19:33:37] 10Release-Engineering-Team (Deployment Training Requests): Deployment training request for **cjming** - https://phabricator.wikimedia.org/T285898 (10cjming) [19:34:50] 10Release-Engineering-Team (Deployment Training Requests): Deployment training request for **cjming** - https://phabricator.wikimedia.org/T285898 (10cjming) [19:47:18] (03PS3) 10Ahmon Dancy: Initial Makefile with 'test' target [tools/scap] - 10https://gerrit.wikimedia.org/r/702445 [19:57:29] 10Release-Engineering-Team (Deployment Training Requests): Deployment training request for **cjming** - https://phabricator.wikimedia.org/T285898 (10thcipriani) a:03thcipriani Hi @cjming I added you to the upcoming training on 2021-07-01. I'll leave this task open for now and dump some resources here post-trai... [19:57:37] 10Release-Engineering-Team (Deployment Training Requests): Deployment training request for **cjming** - https://phabricator.wikimedia.org/T285898 (10thcipriani) p:05Triage→03Medium [20:21:04] 10Release-Engineering-Team (Radar), 10MW-on-K8s: The restricted/mediawiki-webserver image should include skins and resources - https://phabricator.wikimedia.org/T285232 (10dduvall) >>! In T285232#7182392, @dduvall wrote: > One idea that comes to mind is to combine the `php-fpm` and `httpd` base images and buil... [20:55:06] (03PS5) 10Ahmon Dancy: Use docker-compose exec instead of ssh [tools/train-dev] - 10https://gerrit.wikimedia.org/r/701993 [20:56:05] (03CR) 10Ahmon Dancy: [V: 03+2 C: 03+2] Use docker-compose exec instead of ssh [tools/train-dev] - 10https://gerrit.wikimedia.org/r/701993 (owner: 10Ahmon Dancy) [21:02:58] (03PS1) 10Ahmon Dancy: Check for required programs before doing any work. [tools/train-dev] - 10https://gerrit.wikimedia.org/r/702466 [21:04:04] (03CR) 10Ahmon Dancy: [V: 03+2 C: 03+2] Check for required programs before doing any work. [tools/train-dev] - 10https://gerrit.wikimedia.org/r/702466 (owner: 10Ahmon Dancy) [21:09:16] (03PS1) 10Ahmon Dancy: Initialize state/train-versions.json file [tools/release] - 10https://gerrit.wikimedia.org/r/702468 (https://phabricator.wikimedia.org/T282824) [21:20:32] (03CR) 10Jeena Huneidi: [C: 03+1] Initialize state/train-versions.json file [tools/release] - 10https://gerrit.wikimedia.org/r/702468 (https://phabricator.wikimedia.org/T282824) (owner: 10Ahmon Dancy) [21:29:02] (03PS1) 10Ahmon Dancy: Update README.md and TRYME.md [tools/train-dev] - 10https://gerrit.wikimedia.org/r/702471 [22:25:09] 10Release-Engineering-Team (Doing), 10GitLab (Initialization), 10User-brennen: Create a GitLab settings script / repo - https://phabricator.wikimedia.org/T284336 (10brennen) This is now at https://gitlab.wikimedia.org/releng/gitlab-settings/ - GPL3 license in repo. [22:26:53] 10Release-Engineering-Team, 10GitLab, 10User-brennen: gitlab-settings: Figure out how to handle options that take an array of strings - https://phabricator.wikimedia.org/T285907 (10brennen) [22:39:17] !log gitlab: creating people, people/wmf, and people/wmf/release-engineering groups; mandating 2fa for people/wmf [22:39:20] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [22:42:47] !log gitlab: published https://gitlab.wikimedia.org/releng/gitlab-settings [22:42:49] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [22:49:15] 10Release-Engineering-Team (Next), 10GitLab, 10User-brennen: gitlab-settings: Figure out how to handle options that take an array of strings - https://phabricator.wikimedia.org/T285907 (10brennen) [23:00:02] 10Release-Engineering-Team (Doing), 10Release, 10Train Deployments, 10User-brennen: 1.37.0-wmf.12 deployment blockers - https://phabricator.wikimedia.org/T281153 (10brennen) End-of-US-day status: Things are looking pretty stable on group1, expect to proceed as usual to all wikis tomorrow. [23:14:57] bd808: re: membership req for people/wmf, i think we're going to do this by team rather than having direct membership in people/wmf, but we are definitely still sorting this out. :) [23:15:24] brennen: cool. I was just clicking buttons mostly :) [23:15:47] you may find however that "by team" is an interesting concept to track [23:16:10] yeah, as i was just saying to thcipriani elsewhere, i just had this vision of my working life tumbling into the chasm of permissions management [23:16:28] having HR reporting lines involved in the gitlab setup for a given user will be goofy over time [23:17:09] i definitely welcome input here, but we've discussed this quite a bit and i'm not sure how else to subdivide the user-level groups [23:17:49] we're hoping to avoid some of the slurry of nonsense that has crept into gerrit permissions [23:17:53] I guess I'd have to ask what the purpose of the user level groups is before I could say much of substance. [23:18:52] I can say that I have been a member of at least 8 "teams" in my 8 years here [23:19:17] so gitlab upstream (and some other projects using gitlab) recommend having one set of groups to track users and then assigning access to projects based on those [23:19:59] we'd mostly like to avoid having a situation where there are groups like "foo-maintainers" [23:20:16] ^ [23:20:39] would rather keep it to one of: [this team works on x] or [this individual works on x] where the latter is just modeled as direct access to the project for that user. [23:20:40] * bd808 wishes you good luck with that [23:20:59] the idea is that real-world organizational groups should be modeled under "people" [23:21:11] and "foo-maintainers" should just be added directly to "foo" [23:21:20] what are the real world organizational groups for technical volunteers? [23:21:32] that is a damn good question you pose. [23:21:45] we are not a company, we are a global movement [23:22:02] user-namespaces/and projects would be my thought there. If there is a group that that maintains several projects then that maps to a "real world" unit [23:22:08] i suspect in practice: one large group for volunteers generally; specific access to projects managed at the level of individual membership in projects. [23:22:14] I can totally see WMF, WMDE, etc groups [23:23:37] so in gerrit there are useful groups: mediawiki, operations, releng, analytics, etc. And then there are groups that gerrit makes us have: "foo-maintainer" that is one person due to gerrit's model of permissions. [23:24:02] the main difference seems to be that we don't need foo-maintainer since you can add users directly to a project. [23:24:36] *nod* that sounds like github's permissions system [23:24:58] this is true, and then the question is: what's the threshold for a group? [23:25:05] given that gitlab is unabashedly a shameless clone of github in as many respects as they can manage... :) [23:25:13] when you have two projects not in the same top-level namespace? [23:25:13] a repo is owned by an individual or an "org" account. and then users can be added from outside the group etc [23:25:58] foo/project and bar/project -> you now need a people/foo-and-bar group that owns both foo/ and bar/? [23:26:43] If I'm following, the project namespaces are distinct from the groups? [23:26:55] unfortunately not [23:27:12] it's a bunch of namespaces [23:27:20] and each namespace can have members and projects [23:27:30] and the members can be other namespaces [23:27:39] ok, that's back to being github like [23:28:35] yeah, github-like seems right [23:29:21] it's like running github and at somepoint we have to think about easing onboarding and offboarding, I guess [23:30:18] we could just throw up our hands and manage everything at the level of mapping persons to projects, but i think there's quite a bit of benefit in "ok, you've joined releng, you now have access to all the releng stuff". [23:30:48] which may include various projects under different top-level namespaces [23:31:07] (currently "blubber" "tools" and "releng") [23:31:28] kind of right from the start you have to think about it :) there are going to be people onboarded constantly (e.g. new Developer accounts) and offboarded regularly (500+ staff means someone always coming and going) [23:31:56] yeah, there's going to be some admin overhead here no matter what. [23:32:35] so I think that maybe we're going down the right path with having "people/[group-of-people]" namespaces [23:32:39] the genuinely painful case is probably "ok WMF has a new CTO everybody's on a new team and oh by the way still responsible for all their old stuff have fun!" [23:33:21] that is 95% likely to happen before the next VCS replatforming [23:33:41] 8 years, 8 teams :) [23:35:15] yeah, i hear you. [23:36:17] I think I understand that one of the things you are trying to optimize for is staff onboarding/offboarding [23:36:43] that's correct [23:36:50] that makes sense because of all the ways that things get twisted up with Foundation employment [23:37:07] "all problems in computer science can be solved by adding another layer of indirection, except for the problem of too many layers of indirection". [23:37:30] so I think I want to revise the proposal from https://www.mediawiki.org/wiki/GitLab/Policy of "people/wmf/release-engineering" -> "people/wmf" and "people/release-engineering" and try to limit nesting and weird knock-on effects [23:37:51] we could add groups that model functional relationships to projects (or groups of projects), and in turn add other groups of people to _those_, but that sounds... pretty hellish to manage. [23:38:48] I still think "real world grouop" is a good heuristic for when to add a group to "people/[group]" vs adding people directly to a project [23:38:51] hmm, so wmf employees are people/wmf but also teams are people/[team-name]? [23:39:40] I say this because of the doc, "When you add a member to a group, that member is also added to all subgroups" [23:39:58] so a member of "people/wmf" is a member of "people/wmf/release-engineering" [23:40:05] which makes sense when you think about repos [23:40:20] but makes less sense if you're trying to narrow permissions by nesting subgroups [23:40:46] ah, yeah, that's sort of a crucial detail... but also doesn't that make people/ effectively useless? [23:40:57] er, nevermind. [23:41:20] do y'all have a scenario for using the people/wmf group other than as a container for smaller groups? [23:41:36] my main one is things like mandating 2fa. [23:41:50] why would that be by employment status? [23:41:53] do we have to do that at the group level? [23:42:06] can we do that at the instance level? or maybe just at the "people" level? [23:42:39] i.e., if you want to work on a project outside of your username sandbox then you must have 2fa? [23:42:45] we could mandate it for all users; our thinking when we last discussed this was that it'd be somewhat user-hostile to mandate it for everybody, but for folks employed at wmf/wmde we could probably get away with it. [23:42:53] * bd808 didn't mean to hijack everyone's day with these random questions [23:43:15] (to be clear, i'd _like_ to mandate it for everybody.) [23:43:27] bd808: you're a regular gadfly :P [23:44:12] I don't remember the "user hostile" discussion honestly [23:44:32] seems like free hosting if you secure your account is reasonable [23:44:55] yeah, in 2021 i think so, but i vaguely remember some sentiment that it was an extra barrier to contribution. [23:45:21] (more of a barrier than gerrit? probably not.) [23:45:25] if you are thinking that a user must setup 2fa to give a drive-by patch... that sounds yucky [23:45:40] yeah, that's what the earlier conversation boiled down to. [23:45:44] Mandating 2FA also means there's going to be an even higher flow of requests for "lost my phone, need 2FA reset" requests [23:45:56] that's a good point [23:45:57] ^ that is 100% guaranteed [23:46:23] i think what we actually concluded was more along the lines of: if you have rights to merge anything, 2fa. [23:46:38] we only have about 1 of those a month for Horizon/Wikitech but a very small percentage of Cloud users are project admins (where we require it) [23:46:59] (merge anything outside of your user namespace, that is.) [23:47:21] brennen: I think that's reasonable, maybe qualified a bit further of "merge anything to a repo deployed to Wikimedia production" (where "production" needs some further definition) [23:47:30] legoktm: yeah. [23:47:32] well, so I guess it seems like the at least a people/2fa namespace is useful :P [23:47:33] mandating 2FA for a shared Toolforge tool seems a bit overkill [23:48:24] I started using the term "wikiprod" vs "toolforge/wmcs". It's not yet helpful since I have to explain it whenever I say it, but a universal similar term would be peachy. [23:48:51] yeah, I was getting ready to ask about the "right" model for Striker managed Toolforge tool repos [23:49:33] how is that setup in phab? [23:49:39] er..diffusion [23:50:26] it's kind of gross... when the repo is created all the tool mantainers are added to the owner ACL, but then it has to be manually managed [23:50:30] A long time ago I asked if it would be possible to use the Toolforge tool ACLs in Gerrit, it would be nice if that could be done in GitLab, whether automatically or something like Striker syncing the two [23:50:57] the toolforge tool membership is in LDAP [23:51:09] but AIUI not in a way that is consumable by Gerrit [23:51:28] something _might_ be possible there but this is pretty fuzzy in my head. [23:51:37] no idea about that. I never fell into the gerrit internals rabbithole [23:51:50] lucky :) [23:51:52] (possible in terms of using that info for gitlab, that is) [23:52:12] thcipriani: I just gave Chad nice things and he took care of it ;) [23:52:57] a good lesson in there about open source [23:53:13] tool accounts in Toolforge are 1) a service user and 2) a unix group containing the service user and all maintainers [23:54:01] sure seems like it'd be nice to have that unix group modled in the code hosting system [23:54:17] that's a decent "real-world group" [23:55:04] well...maybe...or maybe that's exactly assigning people directly to repos [23:55:59] yeah, honestly I would naively say that having a namespace for toolforge hosted tools with each repo having per-repo permissions is reasonable [23:56:27] which is kind of sort of https://github.com/toolforge/ [23:56:56] yeah, basically [23:57:47] that org account has a "wmcsadmins" team that is used as a shared ACL group within it [23:58:16] relatedly, are we allowed to use gitlab.wikimedia.org now? I saw that add.shore pushed some stuff there the other day [23:58:23] alright so new thought: if the only use-case for people/wmf is 2fa enforcement, then maybe it's "people/trusted-contributors" (that requires 2fa) and "people/[wmf/wmcs-team]" that eases onboarding and offboarding? [23:58:44] legoktm: IIRC it's open for projects under user namespaces (correct me if I'm wrong brennen ) [23:58:49] yeah, correct [23:59:06] ...the backscroll here is us figuring out where to put everything else [23:59:09] can I add other contributors to that project?