ChanServ changed the topic of #freedesktop to:
ngcortes has quit [Remote host closed the connection]
veganaiZe has joined #freedesktop
marcheu has quit [Read error: Connection reset by peer]
marcheu has joined #freedesktop
jarthur has joined #freedesktop
veganaiZe has quit [Quit: veganaiZe]
thaller__ has joined #freedesktop
thaller__ has left #freedesktop [#freedesktop]
thaller_ has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #freedesktop
bengal has joined #freedesktop
bengal has quit []
danvet has joined #freedesktop
bengal has joined #freedesktop
bengal has quit []
<bentiss> karolherbst: what was the bottleneck? the download or the server-side compression?
<bentiss> karolherbst: we now have 3 gitaly servers on 3 different machines, so that's the best we can do (well, we can always spin up a 4th one, but not sure this will help a lot)
bcarvalho has quit [Remote host closed the connection]
<karolherbst> bentiss: just forking through the web interface
<karolherbst> I thought you mentioned something could be changed in order to make that done in an instant
bengal has joined #freedesktop
bengal has quit []
<MrCooper> getting some slow responses and 502s from GitLab
bcarvalho has joined #freedesktop
bengal has joined #freedesktop
xexaxo has quit [Ping timeout: 480 seconds]
<bentiss> karolherbst: well, maybe I was wrong and it still clones the rpo, then add the deduplication and run gc, so 10-15 min is not surprising in that case
<bentiss> karolherbst: I think if you fork a kernel tree on gitlab.com 10-15 min is what you have too
<karolherbst> bentiss: mhh.. annoying :(
<hakzsam> 502 Bad Gateway with gitlab fdo atm
<bentiss> backup is still running... so please wait a bit :(
<hakzsam> np
<bentiss> daniels: I wonder if we should not put some pod affinity and have webservice, redis, postgres, gitaly and shell only running on the servers, and assign the rest on larges
<bentiss> well, another thing to do is to upgrade ceph
<bentiss> which, BTW, works correctly with the local tests I did this week
xexaxo has joined #freedesktop
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #freedesktop
bcarvalho has quit [Remote host closed the connection]
bcarvalho has joined #freedesktop
aleksander has joined #freedesktop
<cwabbott> freedesktop is 500'ing again
Kayden has quit [Read error: Connection reset by peer]
Kayden has joined #freedesktop
<daniels> cwabbott: where? on the core web service? registry? other?
<cwabbott> the core website
<cwabbott> seems like it's back now
<bentiss> kicking the registry cache, it seems to act weird
xexaxo has quit [Remote host closed the connection]
xexaxo has joined #freedesktop
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #freedesktop
<karolherbst> bentiss: so there is no way of speeding up the process of users creating a fork on gitlab from drm/nouveau ?
<bentiss> karolherbst: not that I am aware of
<karolherbst> mhh
<bentiss> karolherbst: I just checked pmoreau/nouveau is on the same server than drm/nouveau, so unless we hack into gitaly (which you don't want to), I don't think we can go faster
<karolherbst> I thought there was this idea to keep everything on one instance where things just happen instantly?
<karolherbst> uhhhh
<bentiss> karolherbst: I thought too, but I was wrong
<karolherbst> that's..... annoying
<bentiss> it's a one time operation
<karolherbst> any idea why it's so slow?
<bentiss> git clone, git gc with a remap of all objects takes time
<karolherbst> sure
<karolherbst> but github is done in like 5 seconds
<bentiss> don't know what magic they are using
<bentiss> there might be an upstream gitlab bug for that
<karolherbst> there actually is
<karolherbst> from 2016
aleksander has quit [Quit: Leaving]
<bentiss> karolherbst: any link?
<karolherbst> but I think it's on the wrong repo
<karolherbst> ehh
<karolherbst> wait
<karolherbst> that's for a specific repo
<karolherbst> mhhh
<bentiss> seems related to what we have. gitlab's code repo is quite big too
<karolherbst> I suspect that github just manages all forks inside the same git repository
<karolherbst> as you can point to commits in forks in the "original" repo
<bentiss> in gitlab you can point to any commit from a fork *if a MR was opened for this branch*
<karolherbst> yeah.. in github it works regardless
<bentiss> oh, ok
<karolherbst> let me verify though
<karolherbst> ahh right
<karolherbst> there is a warning now
<bentiss> so maybe a fork on github is not a true fork :)
<karolherbst> yeah
<karolherbst> that's my assumption
<karolherbst> forks also take close to no space
<bentiss> makes sense then :)
<karolherbst> bentiss: but running git gc could happen asynchronously or so...
<karolherbst> but I guess you can't really improve it through some magic settings or so?
<karolherbst> in the end it's just annoying, but...
<karolherbst> imagine the user wanting to push a simple patch and has to wait like an hour because it's slow
<bentiss> karolherbst: agree, but yeah, not sure we can do better
Kayden has quit [Read error: Connection reset by peer]
Kayden has joined #freedesktop
karolherbst has quit [Remote host closed the connection]
karolherbst has joined #freedesktop
xexaxo has quit [Ping timeout: 480 seconds]
karolherbst has quit [Quit: Konversation terminated!]
karolherbst has joined #freedesktop
fso has joined #freedesktop
xexaxo has joined #freedesktop
fso has quit []
ngcortes has joined #freedesktop
ngcortes has quit [Ping timeout: 480 seconds]
eric_engestrom has quit [Ping timeout: 480 seconds]
narmstrong has quit [Ping timeout: 480 seconds]
cwabbott has quit [Ping timeout: 480 seconds]
zzag has quit [Ping timeout: 480 seconds]
jjardon has quit [Ping timeout: 480 seconds]
ngcortes has joined #freedesktop
ngcortes has quit [Ping timeout: 480 seconds]
ngcortes has joined #freedesktop
xexaxo has quit [Read error: Connection reset by peer]
xexaxo has joined #freedesktop
bengal has quit [Ping timeout: 481 seconds]
danvet has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]