07:22 <eric_engestrom> bentiss: I just checked mesa/mesa, the vars are there (I should've checked before asking here)

07:22 <bentiss> eric_engestrom: no worries

07:22 <eric_engestrom> but what about forks? can they use the default registry?

07:22 <bentiss> eric_engestrom: which jobs were failing?

07:23 <eric_engestrom> like, if an image is pushed to harbor., a fork can't pull it from registry., right?

07:23 <bentiss> eric_engestrom: yes. when you directly push on harbor, it also replicates on registry.fd.o, but with a small delay

07:23 <eric_engestrom> ah ok, I thought it didn't

07:24 <bentiss> heh, I tried to make things as much transparent as possible

07:24 <bentiss> but in the near future, we might not need harbor anymore, if I manage to do all I want when we migrate to gitlab 16.0

08:01 <eric_engestrom> oh nice

08:01 <eric_engestrom> I thought things were moving in the opposite direction, moving everything to harbor because it gives better control

08:01 <eric_engestrom> I guess I missed/misunderstood a bunch of things ^^

08:04 <bentiss> well, the problem with the original registry is that there is no way we can do garbage collection. So we basically have space that is used for nothing. That space doesn't cost a lot on google, but would impact us on our servers. But with the new registry gitlab has, we can have gc, and all projects migrated a few months ago (transparently). I haven't migrated personal

08:04 <bentiss> registries, so they might get reset when we move

08:05 <bentiss> harbor is a temporary solution to our problem for well used images. This way, we don't pull everytime from google which costs a lot

08:07 <eric_engestrom> ok

08:07 <eric_engestrom> so the gc part is fixed on gl, but the pull for frequent images is still an issue, but you still want to go back to gitlab's registry?

08:20 <bentiss> yeah, the gitlab's registry is better integrated with gitlab. You can use it with internal repositories whcih we can not with harbor. The problem is where the data is stored, and the internal one is currently hosted on google. In 16.0 I'll move that data on our cluster, and all the limitations of who pull what gets pointless

08:21 <bentiss> we use harbor as just a cache, but for selected projects, which are using other runners we don't control enforcing harbor at the project level ensures those runners will pick the images from harbor but not registry.fd.o

08:36 <eric_engestrom> I'm having trouble parsing the last sentence, but I think you're saying that runners you don't control fetch from registry. because you can't make them go to harbor.

08:55 <bentiss> eric_engestrom: yeah, exactly. To be able to transparently pull from harbor, you need podman, because the cache url is slightly different, and podman handles that in the config, while docker doesn't

08:56 <eric_engestrom> ack

08:56 <eric_engestrom> thanks for all the explanations :)

08:56 <bentiss> no worries

08:57 <eric_engestrom> is that podman config something that gets propagated through env or something, or does it need to be set on the runner?

08:57 <eric_engestrom> if the latter, then maybe that's what's missing on some of our runners

09:00 <bentiss> the latter

09:01 <bentiss> but I'm more concerned about all the various HW specific farms than htz

09:10 <bentiss> BTW, security update incoming

09:11 <bentiss> (almost forgot about that one)

09:16 <eric_engestrom> yeah I'm thinking about the valve farm right now

09:16 <eric_engestrom> the "mupuf farm"

09:38 <bentiss> IIRC the mupuf farm has its own cache, so it's not an issue

10:00 <daniels> bentiss: ahhh, I didn't realise that detail about cache in podman vs. docker

10:01 <bentiss> daniels: rpeviously we could use docker with the docker cahce deployment, but it required a reset every 7 days, while harbor is pretty much fire and forget :/

10:03 <daniels> heh

10:22 <eric_engestrom> anholt: I think you're one managing Marge? it just said "Something seems broken on my local git repo; check my logs!"

10:22 <eric_engestrom> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23415#note_1946509

10:24 <eric_engestrom> (or perhaps daniels ^)

10:25 <eric_engestrom> hmm, marge seems to have moved on to other MRs and rebased them correctly, so let's just wait and try again

10:26 <daniels> yep, it's a weird transient error

10:27 <daniels> looks like it got restarted and ended up with a git repo that was partially checked out with an inconsistent state, and it didn't know to bail on it

10:27 <daniels> but it's fine now

10:27 <daniels> if it happens more than once every few months, we can try to make it robust

10:46 <eric_engestrom> yeah I think it's not worth investigating at this time

10:46 <eric_engestrom> thanks for checking daniels :)

10:48 <daniels> np!

11:13 <eric_engestrom> mesa-ci-x86-64-lava-lima has run out of disk

11:13 <eric_engestrom> https://gitlab.freedesktop.org/mesa/mesa/-/jobs/43279956

11:13 <eric_engestrom> sorry, copied the wrong line

11:13 <eric_engestrom> mesa-lava-lima-meson-gxl-s805x-libretech-ac

11:15 <eric_engestrom> also, now that I have that ability: should I pause runners when they have issues like this?

11:20 <daniels> sure, go for it

20:58 <dok> hi, I am having issues with my graphics card (pitcairn) radeon nor amdgpu drivers work since a crash while playing yesterday. I am not sure if this is the right place to ask for help

21:00 <pixelcluster> #radeon would be the best place I think :)

21:01 <dok> thanks