Page locked

This page is currently locked for editing by another user. You have to wait until this user finishes editing or the lock expires.

Currently locked by: 216.73.216.98
Lock expires at: 2025/09/13 04:52 (13 min)

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.

======= Gitlab =======

Gitlab is currently on major version 14. This needs to be updated to the current version 15 release this summer, regardless of the repository storage option chosen

====== Storage ======

===== Problem Overview =====
Gitlab has deprecated support for direct repository storage where the repositories are stored either locally, or through and NFS share, and gitlab accesses those directly. The new model of repository storage is to use Gitaly, which provides high-level RPC access to Git repositories. It is used by GitLab to read and write Git data.

===== Options =====

==== Keep Direct access NFS Repositories ====

This option would keep the existing method of repository storage with git repositories stored on the SoCS File server and served to Gitlab using NFS. This is not a realistic long term option, but may allow time to make a decision and purchase any required hardware.

=== Benefits ===
  * Easiest to upgrade - no changes to configuration
  * NFS file server has ample storage space - no new hardware currently necessary

=== Drawbacks ===
  * NFS is no longer officially supported by Gitlab - we would be on our own for software support regarding repos
  * No redundancy in storage (HA)

==== Single Gitlab Omnibus Gitaly Install ====

Using the existing gitlab omnibus package, enable gitaly on the current gitlab server and migrate repositories to being hosted locally.

=== Benefits ===
  * Simplest install method to be ensure our installation is supported

=== Drawbacks ===
  * May not have enough storage on VM node to accommodate all repositories
  * May need to more actively prune old projects
  * No redundancy in storage (HA)
  * Added hardware (storage) may be necessary

=== Gitaly Cluster ====

Use the current gitlab server for most gitlab components, however install gitaly on multiple servers (minimum 3). Repositories would be stored on as many servers as stated by the replication factor.

=== Benefits ===
  * Best performance - IO is spread out over multiple servers
  * Storage spread over servers may defer hardware upgrades over single gitaly instance
  * In compliance for gitlab support
  * Redundant storage (HA)

=== Drawbacks ===
  * Most complex to set up and maintain
  * May still require new hardware (storage) as current VM storage is limited

==== Move to hosted Gitlab ====
Gitlab offers instances of the software hosted by them

=== Benefits ===
  * All responsibility for hardware and software support offloaded

=== Drawbacks ===
  * Costs may be prohibitive
  * Would need to more actively prude accounts and repos
  * Potential difficulty integrating with central logon ID