Opened 2 years ago

Closed 12 months ago

#20821 closed task (fixed)

VM to install gitlab

Reported by: hiro Owned by: tpa
Priority: Medium Milestone:
Component: Internal Services/Tor Sysadmin Team Version:
Severity: Normal Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


I should setup gitlab for the network team to test and will need a VM to do so.


Child Tickets

Change History (15)

comment:1 Changed 2 years ago by hiro

Bumping this up a bit since it is a blocker for me.

comment:2 Changed 2 years ago by hiro

Priority: LowMedium

comment:3 Changed 2 years ago by qbi

Component: Internal ServicesInternal Services/Tor Sysadmin Team
Owner: set to tpa

comment:4 Changed 2 years ago by hiro

Gitlab standard installation requirements are listed here:
Disk space will depend of the repositories that we need to host.
Recommended RAM is 4GB.

comment:5 Changed 2 years ago by qbi

How much is the size of the current repos?

comment:6 Changed 2 years ago by dgoulet

Seems there are some confusion about this so I'll layout what network team wants from that Gitlab.

For now, we only want to use Gitlab for code review which implies two things. Either we link our personal user repository to that instance (mount bind or what not) or we isolate the instance to have some new personal repository in there for each users that we'll use to push the code for review (currently what we do with

Both works for us, of course it would be much easier to link our current git/user/... repo in there but if too complicated, let's not go overboard. Furthermore, IN NO CIRCUMSTANCES that gitlab instance should be able to write to our tpo git. So it MUST be Read-Only if we pull it off.

Depending on what is chosen here, I guess you can du -sh at least the personal repository of asn, dgoulet, nickm, teor, isis, Yawning to have an idea of how much we push (for little-t tor).

This instance will NOT be used for anything else for now. Moving our trac ticketing to a Gitlab instance is a whole new big project itself and not in scope for this.

comment:7 Changed 2 years ago by Sebastian

The current size of all repos is 12GB, btw. gitlab doesn't support deduplication afaik, just like our current infrastructure doesn't.

comment:8 Changed 2 years ago by teor

(du on my repository won't work, as it's on github. The figure you want is 423 MB.)

comment:9 Changed 2 years ago by hiro

Do we have agreement on what is needed for the VM? If we do I could start installing and configuring gitlab.

comment:10 Changed 2 years ago by hiro

What is the status of this? :)
I think this might be an important test as we might consider gitlab adoption also for other team. Let me know if you want me to go ahead with it.

comment:11 Changed 2 years ago by hiro


Replying off-line to a few questions that were raised when discussing about the Gitlab instance setup.
the main concern I think is being able to safely run Gitlab without having the risk of accidental commits or write ups of our codebase.

In this sense, Gitlab itself has a system of role and permissions that can be managed. Please see for more info. This would manage permissions on Gitlab side. Some of this setup is hardcoded in the installation and would probably need an attacker to have access to the machine to mess with it.

Said this, in case we do not feel happy with this solution, we could always restrict access in git to the instance. I haven't researched this fully, but if it is needed I could do this before moving forward with provisioning the machine.

Another possible solution that we could explore is the idea to run gitlab as a complete different remote and the members of the team using the repositories will have to take care to sync to Tor git remote when they want to merge and/or release something. Personally I would start with this solution. But not sure this is what the network team does want.

comment:12 Changed 2 years ago by arma

I'm only going on what's in this ticket, and I hear there have been other discussions but I haven't followed them.

That said, the idea of connecting gitlab to our git repos, in a way where if the gitlab acts badly enough it can write to our git repos, does freak me out a little bit.

Don't we have gitweb sync from git periodically, in a you-can-read-but-you-can't-write way? I wonder if we could have gitlab sync from git periodically too?

comment:13 Changed 2 years ago by arma

Also, do we actually need the 4 gigs of ram to start off with, even with those (relatively) small repositories? It's ok if so, but I bet that could mean we'll need to ask weasel-or-somebody to get a new Hetzner machine to fit this thing, and if so we should know that we're asking for that too.

comment:14 Changed 2 years ago by arma

All of this said, the network team is really excited to have their own gitlab, so let's try to move this forward. What remains? A convincing story for how a malicious gitlab won't hurt things too much, and a confirmation of how much ram we think it'll need? Did I miss anything?

We already have a person lined up to configure and admin the gitlab (hiro), and a group of people excited to use it (the network team).

comment:15 Changed 12 months ago by weasel

Resolution: fixed
Status: newclosed

Right now our gitlab seems to run nicely elsewhere.

<hiro> you can close all of them thanks weasel

Note: See TracTickets for help on using tickets.