[06:19:09] andrewbogott: Yes, please ignore, or just ack for a few days. I can't seem to find the alerts. Should be done sometime this week [07:05:42] morning [08:36:43] b.d808: if you need more quota you can ask for more (you can also clean up with `toolforge build clean` and try to make space). No idea of the context though, so might not apply [08:46:21] good morning [08:46:26] any thoughts on this? T364113 [08:46:28] T364113: toolforge: identify and cache in our container registry all kyverno images - https://phabricator.wikimedia.org/T364113 [09:08:39] * dcaro is rebooting+ upgrading the laptop [09:10:40] arturo: sounds ok to me, we might want to put it in harbor [10:01:00] quick review https://gitlab.wikimedia.org/repos/cloud/toolforge/builds-builder/-/merge_requests/46 [10:11:06] * dcaro lunch [11:08:57] dhinus: thanks! [14:13:26] dcaro: when the buildservice was introduce and a new maintain-kubeusers's managed RBAC was created, do you remember how that was backfilled for existing tool accounts? [14:14:47] I think it was not me who did that [14:14:58] (as in, I was not yet around) [14:15:10] ok [14:15:24] I remember someone doing it kind of "recently", maybe it was taavi [14:16:09] maintain-kubeusers only creates per-tool resources on new account creations. Maybe we could create a proper reconciliation loop [14:16:17] T364312 [14:16:17] T364312: toolforge: introduce some logic to backfill maintain-kubeuser resources (like per-tool kyverno policies) - https://phabricator.wikimedia.org/T364312 [14:16:32] i did a general quota upgrade thing in maintain-kubeusers recently [14:16:53] arturo: maybe have a look at the code removed in https://gitlab.wikimedia.org/repos/cloud/toolforge/maintain-kubeusers/-/commit/9b12808eb87d6c59d8c76bbdff2d8b7b7e58addf? [14:17:38] taavi: I think this exactly what I was looking for, thanks! [14:17:41] https://gitlab.wikimedia.org/repos/cloud/toolforge/maintain-kubeusers/-/commit/9b12808eb87d6c59d8c76bbdff2d8b7b7e58addf#766d7dd2375fd8e3a60b8db9d9a30f6bc2e98a7c_145_107 [14:17:48] that seems to be what you asked no? [14:18:23] yes [14:19:52] * arturo feels the refactor temptation [14:20:11] https://gitlab.wikimedia.org/repos/cloud/toolforge/maintain-kubeusers/-/commit/844f21d480b65e1d58db3529e84576955ddccda6 [14:20:45] right before I started xd [14:21:15] wait, not sure now, maybe a year before? .v. [14:21:53] how would you all feel if maintain-kubeusers is refactored into a more proper reconciliation loop? so we don't need to introduce ducktape code like that everytime we change a resource? [14:22:30] you mean making it a k8s controller? [14:22:42] maybe? [14:22:56] maybe there is something in the ecosystem already? [14:23:40] I would try to avoid it if possible, it's quite more complicated, as you will have to expect to be able to handle almost any state [14:24:20] I was thinking on something similar to the diff algorithm that taavi introduced in the jobs-api [14:25:19] https://gitlab.wikimedia.org/repos/cloud/toolforge/jobs-cli/-/blob/main/tjf_cli/loader.py [14:25:48] I think we can just change all to the latest versions every time we do a change no? [14:25:58] my main worry there is that (apart from the code complexity) making the reconciliation loop more complicated would mean runs take longer, which in turn means setting up a new tool could have additional user-facing slowness [14:26:38] that's another thing, we might want to change the user creation to be event-based, instead of polling [14:27:13] maybe we can put a label in the namespace resource, with a version or something [14:27:25] and bump it when we want resources to be re-created [14:29:04] you mean bump it when it gets updated? [14:29:21] so imagine we have a namespace with label v=1 [14:29:24] (so having a low 'version' means it will be recreated?) [14:29:29] yeah [14:29:47] so we have v=1 in the label, then we introduce a new resource, bump the label to v=2 [14:30:05] that indicates to maintain-kubueusers that all namespaces with v<=2 should be acted on [14:30:16] v<2* [14:30:25] that sounds ok to me [14:32:05] can users update the namespace labels? (I'd guess no?) [14:32:35] that sounds like what what it currently does with quotas on the configmap [14:34:46] yep [14:35:00] (and we half-do with jobs iirc) [15:59:21] * dcaro off [16:00:02] andrewbogott: if you have any good documentation on how to use keystone as idp for a web application, I'll appreciate if you share it :) [16:00:41] I don't but taavi has done it a few times so he'll have ideas [16:00:47] * arturo offline