1 |
Jeremi Piotrowski <jeremi.piotrowski <at> gmail.com> writes: |
2 |
|
3 |
|
4 |
> > > Has anyone attempted to install a self hosted gitlab on gentoo server(s)? |
5 |
|
6 |
|
7 |
> I would deploy it with docker. The gitlab guys push official images of the |
8 |
> main gitlab app[1] and CI runners[2] to dockerhub. That should be |
9 |
> the easiest path to getting it up and running in no time. |
10 |
|
11 |
Docker runs everywhere, including Mesos clusters. |
12 |
|
13 |
> That being said, gitlab does not really play well with clustering in |
14 |
> general. I don't think the main part of the app does any kind of |
15 |
> horizontal scaling (gitlab.com is hosted on a single server) so you need a |
16 |
> fairly beefy server. |
17 |
|
18 |
That's weird. Almost every type of heavy load is finding it's way to |
19 |
clusters now; many via containers some on bare metal clusters. Granted, very |
20 |
often a custom, scheduler/framework has to be modified or custom developed, |
21 |
but I find it hard to believe there is no way to massively speed up |
22 |
something like gitlab on a robust linux cluster. That dragon has been |
23 |
sleighed for most all load problems, be it HPC, networking issues, or |
24 |
security audits, etc etc. Often, a cloud/cluster software can be radically |
25 |
sped up by allocating lots of extra ram to the framework it is running on. |
26 |
Cloud vendors charge way to much for extra ram, so performance of |
27 |
ram-intensive services are often run where there is ample ram. |
28 |
|
29 |
> And while storage should be entirely up to you (the |
30 |
> app _should_ be indifferent to what you use) most folks appear to run with |
31 |
> local disks or NFS. |
32 |
|
33 |
NFS is yesterday's cruft. Many are now using cephfs to replace NFS. Surely a |
34 |
distributed file system (DFS) to work with the (master/slave) nodes in a |
35 |
cluster is also keenly important. Granted the daddy of all cluster file |
36 |
systems (HDFS) is a pig, but it is being actively replaces with a myriad of |
37 |
DFS solutions. Using NFS in a linux cluster turns performance into a |
38 |
cluster*F!!!. Just say no to NFS and learn about DFS. NFS is what clusters |
39 |
used 15 years ago (beowulf/pvm). OrangeFS is an outgrowth if the old PVM |
40 |
and is now part of the kernel (4.6+). |
41 |
|
42 |
Any and all references as to why gitlab crawls, the more technical the |
43 |
better, are of keen interest to me. It's not that I do not believe what you |
44 |
are saying, it just more likely that someone with keen cluster skills has |
45 |
not looked at gitlab. ymmv. The fact of what you are saying that gitlab does |
46 |
not run fast on a cluster, is very bewildering to me, and wreaks of poor |
47 |
architecture on the cluster it was tested on, more than anything else. |
48 |
Scheduler/config/frameworks are properly needed to get large loads to fly on |
49 |
a cluster. At this point, it a lot of work and a bit of black-arts.... |
50 |
Folks with deep pockets, are not failing to make any workload fly, in my |
51 |
extensive research experiences. |
52 |
|
53 |
|
54 |
> > > Any experiences with gitlab are most welcome for comment, good or bad. |
55 |
> > Yes. Bad. Slow, unreactive, eats tons of resources. Doesn't scale with |
56 |
> > large repos (except you have unlimited access to hardware resources). A |
57 |
> > Linux kernel git mirror finally crashed it. |
58 |
|
59 |
What are the specifics of the mirror setup, DFS and the crash? |
60 |
|
61 |
> I can second that - it's slow and load times are long even when performing |
62 |
> the most basic operations such as opening a small file or viewing a single |
63 |
> commit (you _will_ notice - it regulary takes several seconds). Mind you |
64 |
> the gitlab folks are working on improving this since several releases. |
65 |
|
66 |
Sounds like they need a cluster architect to help them select the relevant |
67 |
cluster tools and tune/modify/develop a custom scheduler and frameworks, for |
68 |
each of the sub problems. Also, most projects are fairly clueless about |
69 |
tuning the underlying linux kernels for cluster operations. Stock vendor |
70 |
kernels are 'dog-crap' for linux clusters, but that is another entire set of |
71 |
problems. |
72 |
|
73 |
|
74 |
> As a user, another issue I have with it is that the merge request/review |
75 |
> interface is just terrible. There is _no_ merge request versioning, so |
76 |
> either you submit your code in perfect shape at first try, or any change |
77 |
> (amending/rebasing/merging) will cause the changelist to be duplicated |
78 |
> many times over. You also lose track of the review history instantly - old |
79 |
> comments are either concealed or swallowed. |
80 |
|
81 |
> There is also no CLI utility to automate common review-related tasks |
82 |
> (submitting/responding to review) so you are forced to do everything over |
83 |
> the slow WebUI. |
84 |
|
85 |
That does sound bad... |
86 |
|
87 |
> If you care at all about the codereview aspects, I would recommend gerrit |
88 |
> or phabricator. Both have cli utilities (git-review and arcanist) and |
89 |
> while some claim they are ugly (heard that one especially about |
90 |
> gerrit) they are 100x more practical. |
91 |
|
92 |
> If you only care about having a repository browser then gitlab can work |
93 |
> but there are simpler apps out there (gogs/pagure). |
94 |
|
95 |
Interesting comments. |
96 |
|
97 |
thanks, |
98 |
James |