[09:51:30] arturo: did you get a chance to test https://gitlab.wikimedia.org/repos/cloud/toolforge/lima-kilo/-/merge_requests/227 ? [09:51:59] dhinus: sorry, I forgot. Running it now [09:54:50] no worries, let me know if it works :) [09:56:59] seems to be working so far, at least the lima-vm base image, which is maybe the only thing specific to my laptop [09:57:23] dhinus: would you like to review this? https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/175 [10:03:43] arturo: looking [10:06:16] arturo: approved! [10:06:22] thanks! [10:07:20] I'll merge the lima-kilo MR [10:07:28] yeah let me approve it [10:09:34] dhinus: quick +1 here? https://gitlab.wikimedia.org/repos/cloud/cloud-vps/tofu-infra/-/merge_requests/176 [10:16:19] +1d [10:17:32] thanks! [12:13:32] I have created T391467 let me know if you would rather have that one as a security ticket [12:13:32] T391467: gitlab ci: validate secrets settings in pipeline for tofu integration - https://phabricator.wikimedia.org/T391467 [14:12:02] andrewbogott: remember me why some DNS records were created in "noauth-project"? I think I'll have a go at moving them all to cloudinfra T380484 [14:12:02] T380484: [designate] migrate DNS records in noauth-project to cloudinfra project - https://phabricator.wikimedia.org/T380484 [14:12:46] dhinus: it's because our setup predates multitenancy in designate. [14:13:01] Moving and organizing them would be nice, not sure how much of a mess that'll be. [14:13:32] I did move one zone a few months ago and I think it was easy [14:13:39] of course that doesn't mean the other ones will be :D [14:23:56] moving the zone is straightforward, I assume there's a fair amount of code + tools that sudo-project-id to that zone as well [14:25:02] the one I know of is wmcs-wikireplica-dns.py, but I'm already updating that as part of T374953 [14:25:04] T374953: tofu-infra: replace wmcs-wikireplica-dns.py with tofu - https://phabricator.wikimedia.org/T374953 [14:25:36] there's a few more https://codesearch.wmcloud.org/search/?q=noauth-project&files=&excludeFiles=&repos= [14:25:40] but doesn't seem too bad [14:28:50] tracked in T391486 [14:28:51] T391486: Update scripts that are referencing "noauth-project" for Designate - https://phabricator.wikimedia.org/T391486 [15:28:18] andrewbogott: where is the code responsible of creating PTR records in 16.172.in-addr.arpa. ? [15:28:37] I wonder if moving that zone from noauth-project to cloudinfra (T380495) could break that [15:28:38] everything should be in designate sink handlers [15:28:38] T380495: Migrate "16.172.in-addr.arpa." DNS zone to cloudinfra project - https://phabricator.wikimedia.org/T380495 [15:29:21] I think everything is under puppet/modules/openstack/files/dalmatian/designate [15:29:37] nova_fixed_multi [15:29:45] thanks [15:31:05] it looks like that code is already deriving the correct project to use [15:31:21] let's see if that works :) [15:39:31] yes, I moved the zone, then created a new VM and the PTR record was created correctly! [15:39:55] * dhinus is suprised when things work as they should [15:44:29] I think I gave that nova_fixed_multi a revant recently, to support IPv6, a fixed a couple of edge cases [15:44:51] https://gitlab.wikimedia.org/repos/cloud/cloud-vps/designate-sink-wmcs-nova-fixed-ptr [15:48:29] revamp* [16:02:19] arturo: does that replace the code in operations/puppet? [16:03:18] oops, I thought he just updated the puppet code, if it's in a different repo then I'm behind [16:14:45] anyways the code worked fine :) [16:15:03] but we should check if there's some leftover code in puppet that can be removed [16:20:51] yes, please do [16:21:05] I'm glad it's working w/out noauth [16:21:26] andrewbogott: I have to go offline, I was hoping to get this merged but there's some mysterious flake8 error https://gerrit.wikimedia.org/r/c/operations/puppet/+/1135467 [16:22:09] ah maybe I found it [16:22:33] nope I think I fixed all the ones related to my patch [16:23:22] I think it can wait until tomorrow [16:25:03] * dhinus offline [20:51:32] Toolforge gitlab questions for the room: Should Slavina and Rook retain their owner rights at https://gitlab.wikimedia.org/groups/toolforge-repos/-/group_members? Are there other folks who should have rights there who do not? [20:52:09] did they retain their rights elsewhere? [20:52:27] Seems odd that we would [21:07:22] oh hi Rook :) [21:11:19] Hello! [21:13:08] taavi: It appears that both of them have been removed from the admin tool, but not all other tools & projects. I haven't gone to look, but my suspicion would be that Moritz's offboarding tool only knows about a few things and gitlab group membership is probably not one of them yet. [21:14:18] Being not in the admin tool (no longer Toolforge roots) is probably a sign that dropping the gitlab rights make sense. [21:15:50] We do not have a 1:1 sync there yet. There are folks with admin tool membership who haven't been given the gitlab group rights. But the inverse was previously true; everyone with the gitlab right was also a tools root. [21:18:14] bd808: yeah, tools.admin is in the general "privileged group" list so that would make sense [21:19:34] my general feeling is that we should drop all admin access during offboarding by default, unless they explicitly want to keep the access [21:22:26] I think I would agree. I generally would like it to be possible to leave WMF for whatever reason but still be a Toolforge (or Cloud VPS) admin. That should be a choice however not a default. [21:22:56] Relatedly we should probably think about a "rights not used are removed" policy too [21:23:39] +1 [21:23:45] see also https://phabricator.wikimedia.org/T324052 [21:24:18] my first thought was "keep them only if they want them" which sounds the same as what you're saying? [21:37:03] since I had the screen open I removed the https://gitlab.wikimedia.org/groups/toolforge-repos/ special rights for both r.ook and sstefanova. I would be happy to add either or both back if they decide to get back into tools admin work. [21:37:33] andrewbogott: yeah, that seems to be what taavi and I agree on too.