11:35 <karolherbst> would something break if I'd move `drm/nouveau` over to `nouveau/nouveau`? I'm thinking about making sure all nouveau related stuff is in the same place on gitlab, because currently we have drm/nouveau and the nouveau group with its projects

11:38 <emersion> i think it should be possible to do that with a redirect

11:38 <emersion> if you move the project, i believe GitLab will redirect

11:38 <karolherbst> moving a project adds a redirect anyway, no?

11:39 <emersion> yes, so the breakage if any should be minimal

11:41 <daniels> right, it redirects for ~everything

12:29 <MrCooper> nouveau/nouveau is redundant, would be better to make the project name reflect what it's about

13:00 <karolherbst> then it should rather be nouveau/linux I guess

13:45 <MrCooper> sounds good

13:54 <bentiss> fdo-equinix-m3l-22 is having a bad day...

14:10 <eric_engestrom> bentiss: do you have any idea when you'll be able to upgrade gitlab.fdo to 16.0+ ?

14:11 <bentiss> eric_engestrom: I need to spin up the new cluster, then migrate all of our data first

14:11 <bentiss> and spinning up the cluster took a little bit of effort :(

14:12 <eric_engestrom> yeah, I know it's a major upgrade that will not be easy to do

14:13 <eric_engestrom> it's just that I found a bug in our current version (15.11.11) and when I tried on gitlab.com (16.2.0) it's been fixed, but the documentation incorrectly claims it's always worked since 12.8, so I have no idea when it was actually fixed and started working, but I'm hoping that the next upgrade (16.0 or straight to 16.2?) will include the fix :]

14:14 <eric_engestrom> (for the curious, it's `rules: allow_failure`, it's ignored and has no effect on 15.11.11)

14:15 <eric_engestrom> (trying to make something a hard failure only on Marge pipeline)

14:18 <DavidHeidelberg[m]> bentiss: pretty please, apply the changes with Vignesh being part of restricted traces group :)

14:18 <DavidHeidelberg[m]> 👀

14:20 <daniels> DavidHeidelberg[m]: I already did it

14:21 <DavidHeidelberg[m]> daniels: he's getting 403, something isn't applied

14:21 <DavidHeidelberg[m]> oh, then vignesh I though you just commented it's done by ben... so it was you! :P

14:21 <DavidHeidelberg[m]> *vignesh had right,

14:22 <bentiss> daniels: have you restarted the rook-ceph-rgw-fdo-opa-a deployment?

14:22 <daniels> hmm, I did apply the policy; maybe something needs a restart

14:22 <bentiss> daniels: yeah, the opa policy is stored and applied in each of the rgw deployment

14:23 <bentiss> (FWIW, instead of remembering the proper command I usually just kill the pods one by one :) )

14:24 <DavidHeidelberg[m]> .... and we're back at "have you tried to turn it off and on again?" :D

14:24 <daniels> ha :) I don’t have my laptop with me rn so I’d have to do it tomorrow

14:24 <bentiss> daniels, DavidHeidelberg[m] : doing it right now

14:25 <bentiss> DavidHeidelberg[m]: should be good now

14:26 <DavidHeidelberg[m]> sending a thanks to both, vignesh will now have happy life without 403

14:26 <bentiss> DavidHeidelberg[m]: actually a test would be even better :)

14:32 <DavidHeidelberg[m]> now he gets 404, it's good :D (I think that's our problem)

14:32 <DavidHeidelberg[m]> bentiss: ^

14:33 <bentiss> that's a +1 compared to the previous state, so yeah, definitely better :)

14:36 <DavidHeidelberg[m]> 🤣