Gitlab 9.0 • Hacker News Board

Re: Gitlab 9.0

#161

Post by jacobvosmaer » Thu, Mar 23, 2017, 5:38 PM UTC

jamesmiller5 wrote: post #90

sytse wrote: post #6

Earlier quoted context omitted.

Great to hear you notice the performance improvements. We're very happy with the improvements but we still have long way to go. We want the 99% latency under 1s and right now it is 2s: https://drive.google.com/file/d/0BzQDcBnEfNRZSTZYVXlyc1FGdEk... There are some controller timings that are red https://drive.google.com/a/gitlab.com/file/d/0BzQDcBnEfNRZZV... And the git access timings are a sea of red https://drive.go…

Taking a look at Gitaly & the conversations around it, I don't see much in the way of consensus. Are you using Redis for the distributed lock or is this still a centralized system? My query being you can effectively use the native pre-receive hooks & wrap the git shell to allow consensus without needing to replace git with an RPC system like Gitaly.

> you can effectively use the native pre-receive hooks & wrap the git shell

The way GitLab is organized (pre-Gitaly) makes it very hard to do things like that. Roughly speaking, when handling a push, it is a coordinated dance between GitLab components to make sure it all goes in, but none of these components has full control over the push from start to finish. One of the reasons we are creating Gitaly is to create a 'place' (namely Gitaly) where we _can_ exercise such control.

The other big reason for building it is not having to use Git repos on NFS.

(Gitaly maintainer)

Re: Gitlab 9.0

#162

Post by allover » Thu, Mar 23, 2017, 9:30 PM UTC

stonogo wrote: post #141

allover wrote: post #125

Earlier quoted context omitted.

Perhaps the 'sad'/'damn sidebar'/'should realize' passive-aggressive entitlement doesn't help?

Yes, I'm sure Gitlab's engineers make technical decisions based on this guy's tone in Hacker News comments.

His tone almost guarantees his complaint won't be take seriously.

Also, just being nice is a generally good principle.

Re: Gitlab 9.0

#163

Post by Bombthecat » Fri, Mar 24, 2017, 6:00 PM UTC

sytse wrote: post #43

superplussed wrote: post #41

Earlier quoted context omitted.

I'm glad this is a priority for you guys Sid, the one thing keeping me from using Gitlab is that it doesn't feel as snappy as Github. But as a point of reference, I'm also a guy that won't use Atom because it doesn't feel as snappy as Sublime. For some of us, speed comes first.

Speed is essential for a tool like GitLab that people use intensely. We've made great progress in having better monitoring to see what the cause is. For 9.1 we've scheduled many more performance improvements https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf... than we were able to complete in 9.0 https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf...

What about memory usage?

Re: Gitlab 9.0

#164

Post by jancsika » Fri, Mar 24, 2017, 11:07 PM UTC

ayufan wrote: post #102

jancsika wrote: post #83

I love and use Gitlab and am excited about the 9.0 performance improvements. On the other hand, I found it absurdly difficult to get feedback or action from Gitlab on an MR. There was an MR that fixed a critical problem in the virtualbox runner, and it sat there for about 5 months with no response to either the original submitter or my emails to gitlab/gitlab ci maintainers. About a month ago I finally decided to abu…

Hi janciska, Thanks for writing that comment and making us aware of that case. I'm very sorry that it did that long to get reviewed and merged. The number of issues and merge requests that pass our hands is just crazy and sometimes it happens that some of them are oversight and not properly scheduled. Having people to be persistent, like you, makes them finally to be merged and be part of the product. Thank you for d…

Hi Kamil, Thanks for the reply.

One point may not have been clear-- this isn't just a matter of a single bugfix being available to the userbase sooner rather than later. Rather, it is that multiple iterations through a development cycle were missed. From my rough recollection:

1. There was a problem setting up an OSX guest to work with virtualbox runner on OSX with passwords. We worked around this using pubkey-based auth between guest and host.

2. There was also a timeout issue mentioned on the tracker for which Sam found the relevant code and suggested (but did not create) a fix.

3. Sam seemed to think a snapshot-reuse approach was too complex and likely to hang or fail. I didn't agree and was trying to explore ways in which they could run reliably as it cut CI time in half for my use case.

4. For uploading artifacts, the OSX guest's gitlab-runner binary had the wrong name requiring the user to manually create a symlink with the correct name. (I think this is fixed in 9.0, but not sure since I still have the symlink there and it's still working.)

At the time my CI builds (and probably Sam's) weren't working at all, so we both ate the cost of learning how the CI build system worked in order to debug it. If there had been feedback saying that his MR was the right (or wrong) approach I would have been happy to apply my knowledge gained at the time to the related problems mentioned above in order to debug and eventually fix them.

But now that knowledge is gone. The cost for me to regain it outweighs the benefits of small improvements to what is atm a working if imperfect system.

Edit: formatting