[07:44:58] 10GitLab (Infrastructure), 10serviceops: Reduce usage of public IPv4 addresses on GitLab hosts - https://phabricator.wikimedia.org/T310265 (10ayounsi) My understanding is that it comes down to where we want to implement workarounds to make the current setup works as using interface IPs as VIPs (or having multi... [11:47:13] 10GitLab (Infrastructure), 10Data-Persistence-Backup, 10serviceops, 10serviceops-collab, and 2 others: Backups for GitLab - https://phabricator.wikimedia.org/T274463 (10Jelto) Backups on `gitlab1004` failed today due to full backup disk. There was no error on `gitlab1004`. The backup job exited with ` Aug... [13:51:00] 10GitLab (Infrastructure), 10Data-Persistence-Backup, 10serviceops, 10serviceops-collab, and 2 others: Backups for GitLab - https://phabricator.wikimedia.org/T274463 (10jcrespo) What about integrating gitlab backups with [[ https://phabricator.wikimedia.org/diffusion/OSWB/ | wmfbackups automation ]]? Datab... [13:51:12] GitLab needs a short maintenance break at 14:30 UTC for about 5 minutes. [14:53:16] 10GitLab (CI & Job Runners), 10Security-Team, 10serviceops, 10serviceops-collab, and 3 others: Setup GitLab Runner in trusted environment - https://phabricator.wikimedia.org/T295481 (10Jelto) [14:54:32] 10GitLab (Infrastructure), 10serviceops, 10serviceops-collab, 10Patch-For-Review: Document and test failover for GitLab and GitLab Replica - https://phabricator.wikimedia.org/T296713 (10Jelto) [15:59:32] 10GitLab, 10serviceops, 10serviceops-collab, 10Patch-For-Review: Document and test failover for GitLab and GitLab Replica - https://phabricator.wikimedia.org/T296713 (10Arnoldokoth) [16:00:26] 10GitLab (Infrastructure), 10serviceops, 10serviceops-collab, 10Patch-For-Review: Document and test failover for GitLab and GitLab Replica - https://phabricator.wikimedia.org/T296713 (10Arnoldokoth) [18:20:31] Hi, I want to create repos for some small tools we have in data persistence team, this is my first time using gitlab, so quick q: Do you think we should have a subproject/subgroup in https://gitlab.wikimedia.org/repos/sre for data persistence? I think one subgroup called "dbtools" would be great. And how I can setup runners for it? [18:24:47] brennen: or thcipriani [18:25:55] Amir1: I do think you should have your own group and I can create it for you [18:26:15] Amir1: but I am not sure whether it should exist under /sre/ or not [18:26:28] while the descripton of that says "SRE projects" [18:26:39] there is no existing example for using multi-level team structures [18:26:44] sure, that'd be great, I didn't check 100% if it already exists or not [18:29:31] Amir1: well.. I made one and added you. first time for me as well [18:29:43] and it says members can create groups under it [18:29:54] so you can make /data_persistence/dbtools [18:30:15] it is enforcing 2fa for all members of this project [18:30:41] changed your role from member to maintainer [18:30:55] thanks [18:31:07] let me know if you see it and can yourself add members to it [18:37:50] Amir1: I did something wrong I believe [18:38:07] I haven't done much so far [18:38:08] it should have been /repos/data_persistence/ [18:38:17] then you also get automatic runners [18:38:24] feel free to delete everything and recreate it [18:40:08] ok, so.. I can move it to a new parent.. don't have to delete it.. on it [18:41:00] https://gitlab.wikimedia.org/repos/data_persistence [18:41:55] moved.. but also need to change group URL [18:43:00] thanks [18:43:03] Amir1: ok.. moved under /repos/ done. so this means per: [18:43:04] https://wikitech.wikimedia.org/wiki/GitLab/Gitlab_Runner [18:43:15] the general purpose shared workers [18:43:20] should pick up jobs for you [18:43:31] and you don't have to do anything.. to answer the second question you had [18:43:49] ok awesome, I'm going to give it a try soon [19:54:12] thanks for picking that one up mutante [19:54:18] * brennen just returned from the dentist [19:55:53] brennen: ouch! hope it's ok. Did you have any thoughts on "multi-level" hierarchy? as in /repos/sre/team1 /repos/sre/team2 for SRE subteams [19:56:14] for now I just put that into /repos/ [19:56:42] my stance at this point is: however the folks on the teams feel like organizing the projects. [19:58:08] i had felt like mirroring the structure of any particular _org_ in the layout of the repos was a bad idea to be avoided, but tbh at this point i think i've realized it's inevitable and i'm not especially worried about it. [19:58:16] gitlab will be a mess for the same reasons that gerrit is a mess. [19:58:34] we mostly get along fine with gerrit's layout, why worry, i guess. [20:06:48] well, for this one I did NOT put this under ./sre/ [20:07:09] so we are using team names.. but .. we are not trying to copy the non-existing orgchart either [20:07:30] there can be reorgs as long as they dont rename the teams.. which they will though [20:07:54] but team name does kind of make sense if you want to figure out what group of people should manage certain repos.. so yea [20:08:33] trying to have this perfect tree structure where everything inherits privs and branches represent departments or something..that is too much though [20:08:55] yeah, just not really practical. [20:10:09] data_persistence/dbatools <-- pretends that "data_persistence" isn't even a WMF team name, it's just a description for tools related to people working in the topic area data persistence [20:10:29] and Amir1 leads it, heh [20:18:21] there seem to be roughly 2 approaches.. either centralized or decentralized.. centralized means everybody is annoyed that they have to make tickets and wait for the one or 2 people handling it.. or decentralized where everybody does what they want but it's considered "chaos" and inconsistent where to find stuff you are looking for [20:19:19] the second one is good enough though