[gentoo-user] Gitlab experiences

[gentoo-user] Gitlab experiences

[James]

Hello,

So, from what I've read, gitlab is very popular because you can self-host
and the CI capabilities there are built in. As I look at migrating several
several old mechanical ways to manage code inhouse, gitlab does look
appealing. I do see a variety of packages in via remote overlays::

[1] "cvut" layman/cvut
[2] "dev-zero" layman/dev-zero
[3] "gitlab" layman/gitlab
[4] "maksbotan" layman/maksbotan
[5] "mrueg" layman/mrueg
[6] "rindeal" layman/rindeal
[7] "R_Overlay" layman/R_Overlay
[8] "spike" layman/spike

and dev-go/go-gitlab-client in portage.
 
From the gentoo wiki, it looks like all of the dependencies are already
in portage:: 
https://wiki.gentoo.org/wiki/GitLab#Prerequisites.2FDependencies


Has anyone attempted to install a self hosted gitlab  on gentoo server(s)?
A small gentoo cluster/container setup? Using a Distributed File System,
like cephfs, orangefs or other DFS?

Any experiences with gitlab are most welcome for comment, good or bad.

Re: [gentoo-user] Gitlab experiences

[Rich Freeman]

On Wed, Jul 13, 2016 at 8:44 AM, James <wireless@tampabay.rr.com> wrote:
>
> Has anyone attempted to install a self hosted gitlab  on gentoo server(s)?
> A small gentoo cluster/container setup? Using a Distributed File System,
> like cephfs, orangefs or other DFS?
>

I know the Gentoo Infra team has had negative experiences with hosting
just about anything Java and don't want to go near it.  I don't know
if that is based on specific experiences with GitLab or with just
avoidance with Java in general.  Most of the competing solutions in
this space are also Java-based which is why we don't host any kind of
alternative to Github.

So, take that as a data point or not as you wish.  Certainly
interested to hear what others have found.

One thing I might suggest if there are concerns with maintenance of
Java is that you try to containerize it as much as possible.  Put
Gitlab and its dependencies in a container.  Use config management to
carefully track what need to be changed above the baseline to get it
working.  Put all the storage on mounts hosted outside the container
and bind/network mount them into the container.  Then if things get
out of hand in updates/etc you can just build a new Gitlab container
on each update, apply configuration and mounts, and then test it out.
You could make everything Gitlab depends on essentially disposable
that way.

-- 
Rich

Re: [gentoo-user] Gitlab experiences

[J. García]

El mié, 13-07-2016 a las 09:13 -0400, Rich Freeman escribió:
> On Wed, Jul 13, 2016 at 8:44 AM, James <wireless@tampabay.rr.com>
> wrote:
> > 
> > Has anyone attempted to install a self hosted gitlab  on gentoo
> > server(s)?
> > A small gentoo cluster/container setup? Using a Distributed File
> > System,
> > like cephfs, orangefs or other DFS?
> > 
> 
> I know the Gentoo Infra team has had negative experiences with
> hosting
> just about anything Java and don't want to go near it.  I don't know
> if that is based on specific experiences with GitLab or with just
> avoidance with Java in general.  Most of the competing solutions in
> this space are also Java-based which is why we don't host any kind of
> alternative to Github.
> 

What java has to do with gitlab? according to the repo I see is mostly
ruby code[1](both gitlab and gitlab-ci). what you wrote make it seems
like it is a java app.
In the github mirror of gitlab(the main app), the file stats are:
2,253 Ruby 
697 Haml
319 Markdown
158 CoffeeScript
99 SCSS
90 Cucumber
40 YAML
39 HTML+ERB
26 SVG
25 JavaScript
I have tried it using docker, and it does uses a lot of resources as
someone previously said.

BTW, after I quick look at Gogs it does seem a nice option, very
'github like'. I will try it for sure.

 [1] https://github.com/gitlabhq/gitlabhq

[gentoo-user] Re: Gitlab experiences

[James]

"J." García <jyo.garcia <at> gmail.com> writes:


> > I know the Gentoo Infra team has had negative experiences with
> > hosting
> > just about anything Java and don't want to go near it.  I don't know
> > if that is based on specific experiences with GitLab or with just
> > avoidance with Java in general.  Most of the competing solutions in
> > this space are also Java-based which is why we don't host any kind of
> > alternative to Github.

> What java has to do with gitlab? according to the repo I see is mostly
> ruby code[1](both gitlab and gitlab-ci). what you wrote make it seems
> like it is a java app.
> In the github mirror of gitlab(the main app), the file stats are:
> 2,253 Ruby 
> 697 Haml
> 319 Markdown
> 158 CoffeeScript
> 99 SCSS
> 90 Cucumber
> 40 YAML
> 39 HTML+ERB
> 26 SVG
> 25 JavaScript


Huh. (Double huh...) As Alan is always quick to quip:: JavaScript ain't
java, so that changes the entire game. Performance can be fixed with a
gentoo cluster (yet to be proven). I also read that gitlab is working to
make the "engine" faster.....

> I have tried it using docker, and it does uses a lot of resources as
> someone previously said.

That's what clusters are for. ymmv. Lots of folks are using mesos,
for a variety of workloads. Others like Openstack, which is supported in
gentoo portage. My work on Apache-Mesos is suspended until I finish
up a rack install system I've been hacking on for a while. Apache-Mesos,
that works, can be found in BGO. 

Folks are building mesos cluster on Arm64v8 (Rpi-3) and soon those arm
clusters are going to everywhere, particularly in small companies.... An 8
node cluster for less than $500 USD. (includes 32 cores, 8 arm gpus and 16
gig of ram. So I'm just waiting on an arm64v8 board that has 4 gig of ram each.

> BTW, after I quick look at Gogs it does seem a nice option, very
> 'github like'. I will try it for sure.

For me, robust gentoo support for both Gogs and Gitlab is a good idea
as these are excellent codes to put on a (gentoo) cluster....


>  [1] https://github.com/gitlabhq/gitlabhq

hth,
James

Re: [gentoo-user] Re: Gitlab experiences

[Alan McKinnon]

On 13/07/2016 20:14, James wrote:
> "J." García <jyo.garcia <at> gmail.com> writes:
>
>
>>> I know the Gentoo Infra team has had negative experiences with
>>> hosting
>>> just about anything Java and don't want to go near it.  I don't know
>>> if that is based on specific experiences with GitLab or with just
>>> avoidance with Java in general.  Most of the competing solutions in
>>> this space are also Java-based which is why we don't host any kind of
>>> alternative to Github.
>
>> What java has to do with gitlab? according to the repo I see is mostly
>> ruby code[1](both gitlab and gitlab-ci). what you wrote make it seems
>> like it is a java app.
>> In the github mirror of gitlab(the main app), the file stats are:
>> 2,253 Ruby
>> 697 Haml
>> 319 Markdown
>> 158 CoffeeScript
>> 99 SCSS
>> 90 Cucumber
>> 40 YAML
>> 39 HTML+ERB
>> 26 SVG
>> 25 JavaScript
>
>
> Huh. (Double huh...) As Alan is always quick to quip:: JavaScript ain't
> java, so that changes the entire game. Performance can be fixed with a
> gentoo cluster (yet to be proven). I also read that gitlab is working to
> make the "engine" faster.....

I have two gitlabs at work

The old one which has been broken for yonks since an up grade that went 
terribly bad. New keys for users always made it into the gitlab db, 
never into git's ~/.ssh/authorized_keys, we have a handy script to 
restart the whole damn daemon because it hiccups every other day. Ever 
since a bad upgrade.

The new one sings along, and I moved all my ansible stuff to it. That 
interne did a good job with that projects.

But gitlab isn't Java in any way, don't know why Rich said that - he may 
have conflated gitlab with some other git*. Gitlab is ruby.

With this app, and actually all webapps running in interpreted 
frameworks, I support Rich's idea of running a prebuilt image in a 
container as an appliance. Just mount your storage into the appliance, 
and keep the database somewhere else. I've had too many screwups with 
updates - that ecosystem doesn't seem to care much for upgrade paths 
other than to make sure the dev could git pull daily and it would 
continue to work commit by commit :-)

Alan

Re: [gentoo-user] Gitlab experiences

[Ralf]

Hi James,

On 07/13/16 14:44, James wrote:
> Hello,
> 
> So, from what I've read, gitlab is very popular because you can self-host
> and the CI capabilities there are built in. As I look at migrating several
> several old mechanical ways to manage code inhouse, gitlab does look
> appealing. I do see a variety of packages in via remote overlays::
> 
> [1] "cvut" layman/cvut
> [2] "dev-zero" layman/dev-zero
> [3] "gitlab" layman/gitlab
> [4] "maksbotan" layman/maksbotan
> [5] "mrueg" layman/mrueg
> [6] "rindeal" layman/rindeal
> [7] "R_Overlay" layman/R_Overlay
> [8] "spike" layman/spike
> 
> and dev-go/go-gitlab-client in portage.
>  
> From the gentoo wiki, it looks like all of the dependencies are already
> in portage:: 
> https://wiki.gentoo.org/wiki/GitLab#Prerequisites.2FDependencies
> 
> 
> Has anyone attempted to install a self hosted gitlab  on gentoo server(s)?
> A small gentoo cluster/container setup? Using a Distributed File System,
> like cephfs, orangefs or other DFS?
I recommend to deploy gitlab inside a Debian LXC/Docker container as
Gitlab guys provide and maintain precompiled .deb packages. You do not
want to compile it on your own as it comes with a load of dependencies.
And once dependencies change you really might run into trouble with
gentoo. Gitlab isn't just a tiny one-click-and-it-runs webservice, it's
a whole ecosystem.

For private use, I deployed my Gitlab inside a LXC container on my
Gentoo server box, everything else is really way too much tinkering
around. If you have no other problems in your life, just try it out and
go for it. :-)
> 
> Any experiences with gitlab are most welcome for comment, good or bad.
Yes. Bad. Slow, unreactive, eats tons of resources. Doesn't scale with
large repos (except you have unlimited access to hardware resources). A
Linux kernel git mirror finally crashed it.

That's why I decided to switch to Gogs [1], even for business cases.
Gogs is implemented in Go, has a pretty active and responsive community
and (in my opinion) it is a well-maintained project. Looks and feels
like gitlab but is much faster and consumes a minimum of resources. I
strongly recommend to use Gogs. Just try it out on their website.

They also provide a .deb package, that's the reason why I'm running it
inside a Debian LXC container as well.

HTH
  Ralf

[1] https://gogs.io/
> 
> 

-- 
Ralf Ramsauer
PGP: 0x8F10049B

Re: [gentoo-user] Gitlab experiences

[Rich Freeman]

On Wed, Jul 13, 2016 at 9:19 AM, Ralf
<ralf+gentoo@ramses-pyramidenbau.de> wrote:
> I recommend to deploy gitlab inside a Debian LXC/Docker container as
> Gitlab guys provide and maintain precompiled .deb packages. You do not
> want to compile it on your own as it comes with a load of dependencies.
> And once dependencies change you really might run into trouble with
> gentoo. Gitlab isn't just a tiny one-click-and-it-runs webservice, it's
> a whole ecosystem.

This is part of why I'd suggest not upgrading it in-place.  Just
create a new container from scratch every time there is an update.  Of
course, Gentoo makes this somewhat more painful than other distros; it
tends to be designed around upgrading in-place.

-- 
Rich

Re: [gentoo-user] Gitlab experiences

[Ralf]

Hi Rich,

On 07/13/16 16:35, Rich Freeman wrote:
> On Wed, Jul 13, 2016 at 9:19 AM, Ralf
> <ralf+gentoo@ramses-pyramidenbau.de> wrote:
>> I recommend to deploy gitlab inside a Debian LXC/Docker container as
>> Gitlab guys provide and maintain precompiled .deb packages. You do not
>> want to compile it on your own as it comes with a load of dependencies.
>> And once dependencies change you really might run into trouble with
>> gentoo. Gitlab isn't just a tiny one-click-and-it-runs webservice, it's
>> a whole ecosystem.
> 
> This is part of why I'd suggest not upgrading it in-place.  Just
> create a new container from scratch every time there is an update.  Of
Sure, I totally agree. But from a maintenance point of view this can
become a full-time job very quickly, as gitlab has pretty short
innovation and release cycles. And you do want to install updates very
quickly, especially for web-apps.

  Ralf
> course, Gentoo makes this somewhat more painful than other distros; it
> tends to be designed around upgrading in-place.

[gentoo-user] Re: Gitlab experiences

[James]

Ralf <ralf+gentoo <at> ramses-pyramidenbau.de> writes:


> On 07/13/16 16:35, Rich Freeman wrote:
> > On Wed, Jul 13, 2016 at 9:19 AM, Ralf
> > <ralf+gentoo <at> ramses-pyramidenbau.de> wrote:
> >> I recommend to deploy gitlab inside a Debian LXC/Docker container as
> >> Gitlab guys provide and maintain precompiled .deb packages. You do not
> >> want to compile it on your own as it comes with a load of dependencies.
> >> And once dependencies change you really might run into trouble with
> >> gentoo. Gitlab isn't just a tiny one-click-and-it-runs webservice, it's
> >> a whole ecosystem.

Yep, I heard a bit of bitching about maintaining it. I was contacted by a
corp to install and manage gitlab for them. It's not my cup of tea, so folks
in that space must be upset with maintenance issues....

> > This is part of why I'd suggest not upgrading it in-place.  Just
> > create a new container from scratch every time there is an update. 
> Sure, I totally agree. But from a maintenance point of view this can
> become a full-time job very quickly, as gitlab has pretty short
> innovation and release cycles. And you do want to install updates very
> quickly, especially for web-apps.

Interesting idea. It certainly is a good candidate for codes that stress
a cluster. I'll keep that in mind.

>   Ralf

> > OF course, Gentoo makes this somewhat more painful than other distros; 
> > it tends to be designed around upgrading in-place.

I did not realize it was so java centric...... I'm out, cause I have more
icedtea-java projects than I know what to do with..... (apache-spark).

Thanks for all the info guys,
James

[gentoo-user] Re: Gitlab experiences

[James]

Ralf <ralf+gentoo <at> ramses-pyramidenbau.de> writes:


> > From the gentoo wiki, it looks like all of the dependencies are already
> > in portage:: 
> > https://wiki.gentoo.org/wiki/GitLab#Prerequisites.2FDependencies


> I recommend to deploy gitlab inside a Debian LXC/Docker container as
> Gitlab guys provide and maintain precompiled .deb packages. You do not
> want to compile it on your own as it comes with a load of dependencies.
> And once dependencies change you really might run into trouble with
> gentoo. Gitlab isn't just a tiny one-click-and-it-runs webservice, it's
> a whole ecosystem.

I wonder if using 'app-arch/dpkg' to just install the .deb files on gentoo
would work?  
Issues with using dpkg to install gitlab on gentoo inside a VM/container ?


> For private use, I deployed my Gitlab inside a LXC container on my
> Gentoo server box, everything else is really way too much tinkering
> around. If you have no other problems in your life, just try it out and
> go for it. 

Can you be more specific? Exactly which package(s) did you install this way?
Is debian inside that LXC, or just pure gentoo? Are you using CI with this
configuration?


> > Any experiences with gitlab are most welcome for comment, good or bad.
> Yes. Bad. Slow, unreactive, eats tons of resources. Doesn't scale with
> large repos (except you have unlimited access to hardware resources). A
> Linux kernel git mirror finally crashed it.

On a cluster would be my approach, after the installation issues are ironed
out on a single server install.

> That's why I decided to switch to Gogs [1], even for business cases.
> Gogs is implemented in Go, has a pretty active and responsive community
> and (in my opinion) it is a well-maintained project. Looks and feels
> like gitlab but is much faster and consumes a minimum of resources. I
> strongly recommend to use Gogs. Just try it out on their website.

Is this the gogs package you installed:: www-apps/gogs [1]
[1] "go-overlay" layman/go-overlay

Or did you just use a SaaS/PaaS for Gogs....?


> They also provide a .deb package, that's the reason why I'm running it
> inside a Debian LXC container as well.

And this runs on a gentoo server, with debian inside the LXC? Or on a debian
machine with LXC?  

Have you tried any VCS on a cluster (openstack/mesos/hadoop/others?

curiously,
James

Re: [gentoo-user] Re: Gitlab experiences

[Ralf]

Hi,

On 07/13/16 17:30, James wrote:
> Ralf <ralf+gentoo <at> ramses-pyramidenbau.de> writes:
> 
> 
>>> From the gentoo wiki, it looks like all of the dependencies are already
>>> in portage:: 
>>> https://wiki.gentoo.org/wiki/GitLab#Prerequisites.2FDependencies
Even if all dependency stuff is already inside portage, gitlab itself is
not. So there's no guarantee that gitlab will meet dependency
requirements in future when some packages upgrade or APIs change.
> 
> 
>> I recommend to deploy gitlab inside a Debian LXC/Docker container as
>> Gitlab guys provide and maintain precompiled .deb packages. You do not
>> want to compile it on your own as it comes with a load of dependencies.
>> And once dependencies change you really might run into trouble with
>> gentoo. Gitlab isn't just a tiny one-click-and-it-runs webservice, it's
>> a whole ecosystem.
> 
> I wonder if using 'app-arch/dpkg' to just install the .deb files on gentoo
> would work?  
> Issues with using dpkg to install gitlab on gentoo inside a VM/container ?
Interesting idea, but I never tried it. The gitlab .deb is pretty huge
(~350MiB) and is shipped along with its own webserver, ruby and all that
other dependency monsters and a minimum requirement to external
dependencies. So maybe this is in deed worth a try! Good point.

But what I know for sure that the .deb said to fit to current debian,
where i have kind of a 'guarantee' that it will work in future with
minimum pain. So for me a debian LXC container inside my gentoo box is
the best solution.
> 
> 
>> For private use, I deployed my Gitlab inside a LXC container on my
>> Gentoo server box, everything else is really way too much tinkering
>> around. If you have no other problems in your life, just try it out and
>> go for it. 
> 
> Can you be more specific? Exactly which package(s) did you install this way?
> Is debian inside that LXC, or just pure gentoo? Are you using CI with this
> configuration?
Yes, it's debian inside LXC. And no, I'm not using CI.
> 
> 
>>> Any experiences with gitlab are most welcome for comment, good or bad.
>> Yes. Bad. Slow, unreactive, eats tons of resources. Doesn't scale with
>> large repos (except you have unlimited access to hardware resources). A
>> Linux kernel git mirror finally crashed it.
> 
> On a cluster would be my approach, after the installation issues are ironed
> out on a single server install.
> 
>> That's why I decided to switch to Gogs [1], even for business cases.
>> Gogs is implemented in Go, has a pretty active and responsive community
>> and (in my opinion) it is a well-maintained project. Looks and feels
>> like gitlab but is much faster and consumes a minimum of resources. I
>> strongly recommend to use Gogs. Just try it out on their website.
> 
> Is this the gogs package you installed:: www-apps/gogs [1]
> [1] "go-overlay" layman/go-overlay
> 
> Or did you just use a SaaS/PaaS for Gogs....?
Same here (sorry i was inaccurate): Gogs guys also provide a .deb file.
Same strategy: Debian inside a LXC container on my Gentoo box.
> 
> 
>> They also provide a .deb package, that's the reason why I'm running it
>> inside a Debian LXC container as well.
> 
> And this runs on a gentoo server, with debian inside the LXC? Or on a debian
> machine with LXC?  
Ok, so this is my *private* setup:
Single server box with gentoo on bare-metal, latest bleeding edge stuff.
Nginx on that Gentoo that serves some lightweight sites and webapps
(wordpress, roundcube, usual suspects). Nginx also terminates SSL.

I did not want to install gitlab on gentoo because of its tons of
dependencies. So I run a Debian LXC Container inside Gentoo. Nginx then
reverse-proxies and SSL-terminates the Gitlab LXC container and iptables
forwards the ssh port of the gitlab container.

Updating gitlab to the latest version just costs an apt-get upgrade and
a dozen updates later nothing exploded so far.
> 
> Have you tried any VCS on a cluster (openstack/mesos/hadoop/others?
Nope, not my department.

  Ralf
> 
> curiously,
> James
> 
> 
> 
> 
> 

Re: [gentoo-user] Gitlab experiences

[Jeremi Piotrowski]

On Wed, Jul 13, 2016 at 03:19:00PM +0200, Ralf wrote:
> Hi James,
> 
> On 07/13/16 14:44, James wrote:
> > 
> > Has anyone attempted to install a self hosted gitlab  on gentoo server(s)?
> > A small gentoo cluster/container setup? Using a Distributed File System,
> > like cephfs, orangefs or other DFS?
> I recommend to deploy gitlab inside a Debian LXC/Docker container as
> Gitlab guys provide and maintain precompiled .deb packages. You do not
> want to compile it on your own as it comes with a load of dependencies.
> And once dependencies change you really might run into trouble with
> gentoo. Gitlab isn't just a tiny one-click-and-it-runs webservice, it's
> a whole ecosystem.

I would deploy it with docker. The gitlab guys push official images of the
main gitlab app[1] and CI runners[2] to dockerhub. That should be
the easiest path to getting it up and running in no time.

That being said, gitlab does not really play well with clustering in
general. I don't think the main part of the app does any kind of
horizontal scaling (gitlab.com is hosted on a single server) so you need a
fairly beefy server. And while storage should be entirely up to you (the
app _should_ be indifferent to what you use) most folks appear to run with
local disks or NFS.


> > 
> > Any experiences with gitlab are most welcome for comment, good or bad.
> Yes. Bad. Slow, unreactive, eats tons of resources. Doesn't scale with
> large repos (except you have unlimited access to hardware resources). A
> Linux kernel git mirror finally crashed it.

I can second that - it's slow and load times are long even when performing
the most basic operations such as opening a small file or viewing a single
commit (you _will_ notice - it regulary takes several seconds). Mind you
the gitlab folks are working on improving this since several releases.

As a user, another issue I have with it is that the merge request/review
interface is just terrible. There is _no_ merge request versioning, so
either you submit your code in perfect shape at first try, or any change
(amending/rebasing/merging) will cause the changelist to be duplicated
many times over. You also lose track of the review history instantly - old
comments are either concealed or swallowed.

There is also no CLI utility to automate common review-related tasks
(submitting/responding to review) so you are forced to do everything over
the slow WebUI.

If you care at all about the codereview aspects, I would recommend gerrit
or phabricator. Both have cli utilities (git-review and arcanist) and while
some claim they are ugly (heard that one especially about gerrit) they are
100x more practical. 

If you only care about having a repository browser then gitlab can work
but there are simpler apps out there (gogs/pagure).


[1]: https://hub.docker.com/r/gitlab/gitlab-ce/
[2]: https://hub.docker.com/r/gitlab/gitlab-runner/

[gentoo-user] Re: Gitlab experiences

[James]

Jeremi Piotrowski <jeremi.piotrowski <at> gmail.com> writes:


> > > Has anyone attempted to install a self hosted gitlab  on gentoo server(s)?


> I would deploy it with docker. The gitlab guys push official images of the
> main gitlab app[1] and CI runners[2] to dockerhub. That should be
> the easiest path to getting it up and running in no time.

Docker runs everywhere, including Mesos clusters.

> That being said, gitlab does not really play well with clustering in
> general. I don't think the main part of the app does any kind of
> horizontal scaling (gitlab.com is hosted on a single server) so you need a
> fairly beefy server. 

That's weird. Almost every type of heavy load is finding it's way to
clusters now; many via containers some on bare metal clusters. Granted, very
often a custom, scheduler/framework has to be modified or custom developed,
but I find it hard to believe there is no way to massively speed up
something like gitlab  on a robust linux cluster. That dragon has been
sleighed for most all load problems, be it HPC, networking issues, or
security audits, etc etc. Often, a cloud/cluster software can be radically
sped up by allocating lots of extra ram to the framework it is running on.
Cloud vendors charge way to much for extra ram, so performance of
ram-intensive services are often run where there is ample ram.

> And while storage should be entirely up to you (the
> app _should_ be indifferent to what you use) most folks appear to run with
> local disks or NFS.

NFS is yesterday's cruft. Many are now using cephfs to replace NFS. Surely a
distributed file system (DFS) to work with the (master/slave) nodes in a
cluster is also keenly important. Granted the daddy of all cluster file
systems (HDFS) is a pig, but it is being actively replaces with a myriad of
DFS solutions. Using NFS in a linux cluster turns performance into a
cluster*F!!!. Just say no to NFS and learn about DFS. NFS is what clusters
used 15 years ago (beowulf/pvm). OrangeFS is an outgrowth if the old PVM
and is now part of the kernel (4.6+).

Any and all references as to why gitlab crawls, the more technical the
better, are of keen interest to me. It's not that I do not believe what you
are saying, it just more likely that someone with keen cluster skills has
not looked at gitlab. ymmv. The fact of what you are saying that gitlab does
not run fast on a cluster, is very bewildering to me, and wreaks of poor
architecture on the cluster it was tested on, more than anything else.
Scheduler/config/frameworks are properly needed to get large loads to fly on
a cluster. At this point, it a lot of work and a bit of black-arts....
Folks with deep pockets, are not failing to make any workload fly, in my
extensive research experiences.


> > > Any experiences with gitlab are most welcome for comment, good or bad.
> > Yes. Bad. Slow, unreactive, eats tons of resources. Doesn't scale with
> > large repos (except you have unlimited access to hardware resources). A
> > Linux kernel git mirror finally crashed it.

What are the specifics of the  mirror setup, DFS and the crash?

> I can second that - it's slow and load times are long even when performing
> the most basic operations such as opening a small file or viewing a single
> commit (you _will_ notice - it regulary takes several seconds). Mind you
> the gitlab folks are working on improving this since several releases.

Sounds like they need a cluster architect to help them select the relevant
cluster tools and tune/modify/develop a custom scheduler and frameworks, for
each of the sub problems. Also, most projects are fairly clueless about
tuning the underlying linux kernels for cluster operations. Stock vendor
kernels are 'dog-crap' for linux clusters, but that is another entire set of
problems.


> As a user, another issue I have with it is that the merge request/review
> interface is just terrible. There is _no_ merge request versioning, so
> either you submit your code in perfect shape at first try, or any change
> (amending/rebasing/merging) will cause the changelist to be duplicated
> many times over. You also lose track of the review history instantly - old
> comments are either concealed or swallowed.

> There is also no CLI utility to automate common review-related tasks
> (submitting/responding to review) so you are forced to do everything over
> the slow WebUI.

That does sound bad...

> If you care at all about the codereview aspects, I would recommend gerrit
> or phabricator. Both have cli utilities (git-review and arcanist) and 
> while some claim they are ugly (heard that one especially about 
> gerrit) they are 100x more practical. 

> If you only care about having a repository browser then gitlab can work
> but there are simpler apps out there (gogs/pagure).

Interesting comments.

thanks,
James

Re: [gentoo-user] Re: Gitlab experiences

[Alan McKinnon]

On 13/07/2016 21:13, James wrote:
> Jeremi Piotrowski <jeremi.piotrowski <at> gmail.com> writes:
>
>
>>>> Has anyone attempted to install a self hosted gitlab  on gentoo server(s)?
>
>
>> I would deploy it with docker. The gitlab guys push official images of the
>> main gitlab app[1] and CI runners[2] to dockerhub. That should be
>> the easiest path to getting it up and running in no time.
>
> Docker runs everywhere, including Mesos clusters.
>
>> That being said, gitlab does not really play well with clustering in
>> general. I don't think the main part of the app does any kind of
>> horizontal scaling (gitlab.com is hosted on a single server) so you need a
>> fairly beefy server.
>
> That's weird. Almost every type of heavy load is finding it's way to
> clusters now; many via containers some on bare metal clusters. Granted, very
> often a custom, scheduler/framework has to be modified or custom developed,
> but I find it hard to believe there is no way to massively speed up
> something like gitlab  on a robust linux cluster. That dragon has been
> sleighed for most all load problems, be it HPC, networking issues, or
> security audits, etc etc. Often, a cloud/cluster software can be radically
> sped up by allocating lots of extra ram to the framework it is running on.
> Cloud vendors charge way to much for extra ram, so performance of
> ram-intensive services are often run where there is ample ram.

Depends. It might all be running on a single-threaded ruby process in 
the middleware :-)

Don't laugh, I've seen stranger things.

Alan

[gentoo-user] Re: Gitlab experiences

[James]

Alan McKinnon <alan.mckinnon <at> gmail.com> writes:


> > often a custom, scheduler/framework has to be modified or custom developed,
> > but I find it hard to believe there is no way to massively speed up
> > something like gitlab  on a robust linux cluster. That dragon has been
> > sleighed for most all load problems, be it HPC, networking issues, or
> > security audits, etc etc. Often, a cloud/cluster software can be radically
> > sped up by allocating lots of extra ram to the framework it is running on.
> > Cloud vendors charge way to much for extra ram, so performance of
> > ram-intensive services are often run where there is ample ram.

> Depends. It might all be running on a single-threaded ruby process in 
> the middleware 


If you believe what one reads::

"You seem to be confusing two very different things here: the Ruby
Programming Language and the specific threading model of one specific
implementation of the Ruby Programming Language. There are currently around
11 different implementations of the Ruby Programming Language, with very
different and unique threading models. " circa 2011.

> Don't laugh, I've seen stranger things.
> Alan

There are a multitude of ways to profile codes and the modules. Surely
someone at gitlab has done this? (Evidently No?) A big part of cluster
architecture is to identify the bottlenecks in codes that run on a single
machine and  implement solutions to lessen the bottlenecks. Most modern
codes inherently run parallel and that's what cluster provide, more
resources for many more threads, and the addition of custom hardware, such
as GPUs, DDR5 ram, fpga and different architectures of processors. Surely
gitlab can be fixed with a correctly applied cluster, or the codes that
compose gitlab, need to be fixed...

I'll be the first one to verify, you just don't rent a cluster
(containers/VM) and move you slow applications there and magically
all is fixed. The first step is to identify and qualify/quantify
the source(s) of the bottlnecks.   CS-101.

However, profiling code/kernels/libs often leads one down the 'fuzzer' path,
and that's a whole other (fun) time-sink. 

ymmv,
James

GitPrep? (was: Re: [gentoo-user] Gitlab experiences)

[Andreas K. Huettel]

Am Mittwoch, 13. Juli 2016, 14:44:39 schrieb James:
> Hello,
> 
> So, from what I've read, gitlab is very popular because you can self-host
> and the CI capabilities there are built in. 

[...]

Has anyone here already played with GitPrep?

That looks rather straightforward to package (but I haven't done it yet...)
http://perlcodesample.sakura.ne.jp/gitprep-site/


-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/