ChanServ changed the topic of #freedesktop to: https://www.freedesktop.org infrastructure and online services || for questions about freedesktop.org projects, please see each project's contact || for discussions about specifications, please use https://gitlab.freedesktop.org/xdg or xdg@lists.freedesktop.org
Haaninjo has quit [Quit: Ex-Chat]
busheling has joined #freedesktop
Kayden has quit [Quit: go home]
___nick___ has quit []
___nick___ has joined #freedesktop
___nick___ has quit []
___nick___ has joined #freedesktop
ximion1 has joined #freedesktop
ximion has quit [Ping timeout: 480 seconds]
ximion1 has quit []
ppascher has joined #freedesktop
bilboed0 is now known as bilboed
Kayden has joined #freedesktop
i-garrison has quit [Read error: Connection reset by peer]
i-garrison has joined #freedesktop
ppascher has quit [Quit: Gateway shutdown]
busheling has quit [Remote host closed the connection]
busheling has joined #freedesktop
danvet has joined #freedesktop
alanc has quit [Remote host closed the connection]
<bentiss>
daniels: ^^ I managed to raise the num_locks to 8192 on that runner, but we probably need to edit podman-free-space to only keep a decent amount of volumes
MajorBiscuit has joined #freedesktop
phasta has joined #freedesktop
<mupuf>
bentiss: OMG :o
<bentiss>
actually, given the number of kept volumes, we might want to not raise that limit...
* bentiss
is gathering some numbers on m3l-12, to see what is the weight of the volumes on the disks
<bentiss>
only 2.9 TB...
<mupuf>
bentiss: what's there?
<mupuf>
is it the caches for the containers?
<bentiss>
mupuf: yeah, gitlab-runner keeps a cache of all containers so that they spin up faster without having to pull the git tree and such
<mupuf>
Makes sense!
<bentiss>
well, the disk is 7TB, and used at 3.9TB, so that's ~1 TB of images
* mupuf
should also increase this value in valve-infra too
<bentiss>
mupuf: to be able to bump it: pause the runner, no pods should be running, then drop the file, rm /dev/shm/libpod_lock, then podman system renumber, then systemctl restart podman
<mupuf>
bentiss: rebooting wouldn't be enough? We would need to also call podman system renumber?
<bentiss>
mupuf: yeah, that's what I read in the bug reports. rebooting might work, but this allows to bump the limit without a reboot ;)
<mupuf>
:)
<mupuf>
thanks for the info! I'll make an issue in valve-infra
<bentiss>
no worries. this way we'll have a trace on how to bu,p the limit on the fly :)
<bentiss>
mupuf: yep. And we get those 2048 in 3 weeks
<mupuf>
indeed, but I thought it was 4096, so rather than going from 3 to 6 weeks, you are going from 3 to 12 weeks :)
<bentiss>
the problem is that this will buy some time, but I also need to do some janitoring because there are quite some volumes that will never be used again
<bentiss>
so I'm working on flushing them regularly atm
<mupuf>
yeah, it would be great if podman could keep usage statistics
<mupuf>
I need them for b2c, so I may implement that
<mupuf>
(I would like to implement an LRU policy on volumes and container layers
<mupuf>
and I should definitely implement that directly in podman
<mupuf>
BTW, podman 4.4 is out, with my first commits there. The upstreaming process seems a bit fast and loose, but they have nice tooling
<mupuf>
unreliable, but nice :)
pendingchaos_ has joined #freedesktop
ximion has joined #freedesktop
<bentiss>
heh, congrats :)
pendingchaos__ has joined #freedesktop
pendingchaos has quit [Ping timeout: 480 seconds]
pendingchaos_ has quit [Ping timeout: 480 seconds]
pendingchaos has joined #freedesktop
abrotman has quit [Remote host closed the connection]
abrotman has joined #freedesktop
airlied has quit [Ping timeout: 480 seconds]
pendingchaos__ has quit [Ping timeout: 480 seconds]
<mupuf>
bentiss: thanks, but the point was that working with upstream isn't a hassle
<bentiss>
mupuf: I get that, but it's still always fun to have code accepeted in a new project :)
<bentiss>
I'm glad I managed to figure this one out
<daniels>
I would've never thought to correlate locks and volumes ...
<bentiss>
well, the bugs on github for podman helped a lot :)
AbleBacon has quit [Read error: Connection reset by peer]
phasta has quit [Quit: Leaving]
<eric_engestrom>
I was asked if we should put tests that fail and we don't think we'll ever be able to fix in `-fails` or `-skips`
<eric_engestrom>
I answer that I think we should put them in `-fails` to know if they ever get fixed, but now I'm wondering what others think?
<eric_engestrom>
I get wanting to save resources by not running them if we don't believe they'll ever pass
<daniels>
right, if they're just long-term broken but fail quickly and not noisily then -fails is fine, but if they're either never going to work (for architectural reasons), or fail slowly/loudly (e.g. take out other tests with GPU resets), then -skips makes more sense
<eric_engestrom>
daniels: thx, I guess my view was too simplified/restricted :)
<mupuf>
agreed with what daniels said
vkareh has joined #freedesktop
<MrCooper>
+1
GNUmoon has quit [Remote host closed the connection]