Hi Bjørn, here are some quick answers, I hope you find them usefull:

1. Upgrade gitlab yourself. I don't think the TKL guys are going to keep the up with new versions of the gitlab, as they come out too quickly. And it's a good thing to keep gitlab upgraded.

2. You have to follow the incremental path. I'm not sure which version finally did it to the TKLAppliance, but you'll have to upgrade from there on.

3. You shouldn't run a clone command, instead you should pull, but I can't help you with this as I don't have the appliance running. Why don't you post the specific problems you're getting with the official upgrade instructions to see if I can help you a bit more?

And it's close (I think) but I can't be sure.

I am using the instructions here: https://github.com/gitlabhq/gitlabhq/wiki/From-2.2-and-higher-to-2.9
(as I figure that it probably the most reasonable way to go)

Ok so here is what I have which seems to work ok:

	service redis-server stop
service nginx stop
cd /home/gitlab/gitlab
sudo -u gitlab git init
sudo -u gitlab git remote add origin git://github.com/gitlabhq/gitlabhq.git
sudo -u gitlab git pull origin stable
sudo -u gitlab gem update --system
sudo -u gitlab cp config/gitlab.yml config/gitlab.yml.orig
sudo -u gitlab cp config/gitlab.yml.example config/gitlab.yml

But it all falls over when I run

(important bits in bold)

sudo -u gitlab bundle install --without development test
Fetching gem metadata from http://rubygems.org/.
Error Bundler::HTTPError during request to dependency API
Fetching full source index from http://rubygems.org/
Fetching https://github.com/gitlabhq/grit.git
remote: Counting objects: 5135, done.
remote: Compressing objects: 100% (2802/2802), done.
remote: Total 5135 (delta 2453), reused 4878 (delta 2250)
Receiving objects: 100% (5135/5135), 1.99 MiB | 212 KiB/s, done.
Resolving deltas: 100% (2453/2453), done.
Fetching https://github.com/gitlabhq/grack.git
remote: Counting objects: 149, done.
remote: Compressing objects: 100% (85/85), done.
remote: Total 149 (delta 59), reused 134 (delta 50)
Receiving objects: 100% (149/149), 26.44 KiB | 14 KiB/s, done.
Resolving deltas: 100% (59/59), done.
Fetching https://github.com/gitlabhq/omniauth-ldap.git
remote: Counting objects: 154, done.
remote: Compressing objects: 100% (93/93), done.
remote: Total 154 (delta 51), reused 132 (delta 32)
Receiving objects: 100% (154/154), 76.00 KiB | 15 KiB/s, done.
Resolving deltas: 100% (51/51), done.
Fetching https://github.com/gitlabhq/yaml_db.git
remote: Counting objects: 333, done.
remote: Compressing objects: 100% (144/144), done.
remote: Total 333 (delta 193), reused 296 (delta 161)
Receiving objects: 100% (333/333), 44.06 KiB | 20 KiB/s, done.
Resolving deltas: 100% (193/193), done.
Using rake (0.9.2.2) 
Installing i18n (0.6.1) 
Installing multi_json (1.3.6) 
Installing activesupport (3.2.8) 
Installing builder (3.0.2) 
Installing activemodel (3.2.8) 
Using erubis (2.7.0) 
Installing journey (1.0.4) 
Using rack (1.4.1) 
Using rack-cache (1.2) 
Using rack-test (0.6.1) 
Using hike (1.2.1) 
Using tilt (1.3.3) 
Using sprockets (2.1.3) 
Installing actionpack (3.2.8) 
Installing mime-types (1.19) 
Using polyglot (0.3.3) 
Using treetop (1.4.10) 
Using mail (2.4.4) 
Installing actionmailer (3.2.8) 
Using arel (3.0.2) 
Using tzinfo (0.3.33) 
Installing activerecord (3.2.8) 
Installing activeresource (3.2.8) 
Using bundler (1.1.4) 
Using rack-ssl (1.3.2) 
Installing json (1.7.5) with native extensions 
Using rdoc (3.12) 
Installing thor (0.16.0) 
Installing railties (3.2.8) 
Installing rails (3.2.8) 
Installing acts-as-taggable-on (2.3.1) 
Using bcrypt-ruby (3.0.1) 
Using blankslate (2.1.2.4) 
Installing bootstrap-sass (2.0.4.0) 
Using carrierwave (0.6.2) 
Using charlock_holmes (0.6.8) 
Installing chosen-rails (0.9.8.3) 
Installing coffee-script-source (1.3.3) 
Installing execjs (1.4.0) 
Using coffee-script (2.2.0) 
Using coffee-rails (3.2.2) 
Using colored (1.2) 
Using daemons (1.1.8) 
Installing orm_adapter (0.3.0) 
Installing warden (1.2.1) 
Installing devise (2.1.2) 
Using diff-lcs (1.1.3) 
Installing draper (0.17.0) 
Using escape_utils (0.2.4) 
Using eventmachine (0.12.10) 
Installing multipart-post (1.1.5) 
Installing faraday (0.8.4) 
Installing ffaker (1.14.0) 
Installing sass (3.1.19) 
Installing sass-rails (3.2.5) 
Installing font-awesome-sass-rails (2.0.0.0) 
Installing foreman (0.47.0) 
Installing gemoji (1.1.1) 
Using git (1.2.5) 
Using posix-spawn (0.3.6) 
Installing yajl-ruby (1.1.0) with native extensions 
Installing pygments.rb (0.3.1) 
Installing github-linguist (2.3.4) 
Installing github-markup (0.7.4) 
Installing gitlab_meta (3.0) 
Installing gratr19 (0.4.4.1) 
Using grit (2.5.0) from https://github.com/gitlabhq/grit.git (at 7f35cb9) 
Installing hashery (1.5.0) 
Installing gitolite (1.1.0) 
Using grack (1.0.0) from https://github.com/gitlabhq/grack.git (at master) 
Using hashie (1.2.0) 
Using multi_xml (0.5.1) 
Installing rack-mount (0.8.3) 
Installing grape (0.2.1) 
Installing haml (3.1.6) 
Using haml-rails (0.3.4) 
Using httparty (0.8.3) 
Installing httpauth (0.1) 
Installing jquery-atwho-rails (0.1.6) 
Using jquery-rails (2.0.2) 
Installing jquery-ui-rails (0.5.0) 
Installing jwt (0.1.5) 
Installing kaminari (0.14.0) 
Using kgio (2.7.4) 
Using libv8 (3.3.10.4) 
Installing modernizr (2.5.3) 
Using mysql2 (0.3.11) 
Using net-ldap (0.2.2) 
Installing oauth (0.4.7) 
Installing oauth2 (0.8.0) 
Using omniauth (1.1.0) 
Installing omniauth-oauth2 (1.1.0) 
Installing omniauth-github (1.0.3) 
Installing omniauth-google-oauth2 (0.1.13) 
Using pyu-ruby-sasl (0.0.3.3) 
Using rubyntlm (0.1.1) 
Using omniauth-ldap (1.0.2) from https://github.com/gitlabhq/omniauth-ldap.git (at f038dd8) 
Installing omniauth-oauth (1.0.1) 
Installing omniauth-twitter (0.0.13) 
Installing pg (0.14.0) with native extensions 
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.

        /usr/local/bin/ruby extconf.rb 
checking for pg_config... no
No pg_config... trying anyway. If building fails, please try again with
 --with-pg-config=/path/to/pg_config
checking for libpq-fe.h... no
Can't find the 'libpq-fe.h header
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

provided configuration options:
--with-opt-dir
--without-opt-dir
--with-opt-include
--without-opt-include=${opt-dir}/include
--with-opt-lib
--without-opt-lib=${opt-dir}/lib
--with-make-prog
--without-make-prog
--srcdir=.
--curdir
--ruby=/usr/local/bin/ruby
--with-pg
--without-pg
--with-pg-dir
--without-pg-dir
--with-pg-include
--without-pg-include=${pg-dir}/include
--with-pg-lib
--without-pg-lib=${pg-dir}/lib
--with-pg-config
--without-pg-config
--with-pg_config
--without-pg_config

Gem files will remain installed in /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/pg-0.14.0 for inspection.
Results logged to /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/pg-0.14.0/ext/gem_make.out
An error occured while installing pg (0.14.0), and Bundler cannot continue.
Make sure that `gem install pg -v '0.14.0'` succeeds before bundling.

I tried

sudo -u gitlab gem install pg -v '0.14.0' --without-pg

and

sudo -u gitlab gem install pg -v '0.14.0' --without-pg_config

in the hope that it wasn't really needed (from what I gather the pg gem is to do with PostgreSQL - and the TKL appliance is built with MySQL backend from what I can gather... But they both return "invalid option" errors...

Interestingly enough though, I started playing with this upgrade from another instance, documenting as I went and got past this (but ran into troubles later so I started again). Not sure what that's about...? I'll try again another time...

[update] I think there is a bug and I just had poor timing... The repo has been updated (to v3.0.1) and I think the first time (when it got past this bit) was back with v2.9. I have just posted on the GitLab mailing list and we'll wait to see what happens...

And i seems like the issue I was having before (on my original server) was to do with the SSH key. I just read about it on the GitLab mailinglist.

When I get this sorted I'll post the lot together as a clean post - or perhaps in the wiki or maybe as a TKLPatch 

So I posted on the GitLab mailing list and found out that things have changed a little...

Instead of 

sudo -u gitlab bundle install --without development test

you need to run

sudo -u gitlab bundle install --without development test postgres sqlite

which has got me further, but still not quite there, now I am stuck at the final step

sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production
Starting diagnostics
config/database.yml............exists 
config/gitlab.yml............exists 
/home/git/repositories/............exists 
/home/git/repositories/ is writable?............YES 
remote: Counting objects: 24, done. 
remote: Compressing objects: 100% (17/17), done. 
remote: Total 24 (delta 2), reused 0 (delta 0) 
Receiving objects: 100% (24/24), done. 
Resolving deltas: 100% (2/2), done. 
Can clone gitolite-admin?............YES 
UMASK for .gitolite.rc is 0007? ............YES 
/home/git/.gitolite/hooks/common/post-receive exists? ............NO 

rake aborted! unexpected return Tasks: TOP => gitlab:app:status 
(See full trace by running task with --trace)

But it's definately there (I copied it there and chowned it to git:git as per instructions)

ls -la /home/git/.gitolite/hooks/common/

total 32
drwxr-xr-x 2 git git 4096 Oct 23 21:03 .
drwxr-xr-x 4 git git 4096 Aug 11 14:54 ..
-rw-r--r-- 1 git git    0 Aug 11 14:54 gitolite-hooked
-rw-r--r-- 1 git git  288 Aug 11 14:54 gl-pre-git.hub-sample
-rwxr-xr-x 1 git git  471 Oct 23 21:03 post-receive
-rwxr-xr-x 1 git git  825 Aug 11 14:54 post-receive.mirrorpush
-rwxr-xr-x 1 git git 4348 Aug 11 14:54 update
-rw-r--r-- 1 git git 1405 Aug 11 14:54 update.secondary.sample

I have posted again on the GitLab mailing list but if anyone here has any bright ideas, I'd love to hear them....

[update] I have fixed this issue too now (it is to do with the permissions). Unfortunately I don't have my notes handy, but it's pretty straight forward. Unfortunately it still isn't working... :( It passes all the tests but the GitLab server still refuses to start... I think I'll start again on a fresh TKL GitLab appliance when I get a chance and see how we go from there...

I just saw that GitLab has been updated to 3.0.3 so I tried again to update this appliance from a clean install (#6)... Still no joy though... :(

I just tweaked the code I am using to do this update in the above forum post. It is so frustrating that this doesn't work cause I can't figure out why. Also FYI after reading the above error I posted it seemed that the socket was the problem, with naive optimism I deleted the .socket in #5 but still errors.

The errors I get now (in #6) are:

cat log/unicorn.stderr.log 
I, [2012-10-28T03:04:46.430091 #4095]  INFO -- : listening on addr=/home/gitlab/gitlab//tmp/sockets/gitlab.socket fd=5
I, [2012-10-28T03:04:46.430805 #4095]  INFO -- : Refreshing Gem list
I, [2012-10-28T03:05:08.422747 #4095]  INFO -- : master process ready
I, [2012-10-28T03:05:08.479913 #4135]  INFO -- : worker=0 ready
I, [2012-10-28T03:05:08.495342 #4138]  INFO -- : worker=1 ready
I, [2012-10-28T03:11:11.930897 #4095]  INFO -- : reaped # worker=0
I, [2012-10-28T03:11:11.931046 #4095]  INFO -- : reaped # worker=1
I, [2012-10-28T03:11:11.931136 #4095]  INFO -- : master complete
I, [2012-10-28T03:46:36.162472 #6040]  INFO -- : unlinking existing socket=/home/gitlab/gitlab//tmp/sockets/gitlab.socket
I, [2012-10-28T03:46:36.192208 #6040]  INFO -- : listening on addr=/home/gitlab/gitlab//tmp/sockets/gitlab.socket fd=5
I, [2012-10-28T03:46:36.192752 #6040]  INFO -- : Refreshing Gem list
/home/gitlab/gitlab/app/models/event/push_trait.rb:2:in `': undefined method `as_trait' for Event::PushTrait:Module (NoMethodError)
from /home/gitlab/gitlab/app/models/event/push_trait.rb:1:in `'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:251:in `require'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:251:in `block in require'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:236:in `load_dependency'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:251:in `require'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:359:in `require_or_load'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:313:in `depend_on'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.8/lib/active_support/dependencies.rb:225:in `require_dependency'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/engine.rb:439:in `block (2 levels) in eager_load!'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/engine.rb:438:in `each'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/engine.rb:438:in `block in eager_load!'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/engine.rb:436:in `each'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/engine.rb:436:in `eager_load!'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/application/finisher.rb:53:in `block in '
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:30:in `instance_exec'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:30:in `run'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:55:in `block in run_initializers'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:54:in `each'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/initializable.rb:54:in `run_initializers'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/application.rb:136:in `initialize!'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/railties-3.2.8/lib/rails/railtie/configurable.rb:30:in `method_missing'
from /home/gitlab/gitlab/config/environment.rb:5:in `'
from config.ru:4:in `require'
from config.ru:4:in `block in '
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/builder.rb:51:in `instance_eval'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/rack-1.4.1/lib/rack/builder.rb:51:in `initialize'
from config.ru:1:in `new'
from config.ru:1:in `'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn.rb:44:in `eval'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn.rb:44:in `block in builder'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/bin/unicorn_rails:139:in `call'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/bin/unicorn_rails:139:in `block in rails_builder'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/http_server.rb:696:in `call'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/http_server.rb:696:in `build_app!'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/lib/unicorn/http_server.rb:136:in `start'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/gems/unicorn-4.3.1/bin/unicorn_rails:209:in `'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/bin/unicorn_rails:23:in `load'
from /home/gitlab/gitlab/vendor/bundle/ruby/1.9.1/bin/unicorn_rails:23:in `'

So still no idea what is going on...

Another way to go may be to use the unofficial GitLab Debian repo. See here.

Obviously it is not signed, nor is a known quantity (ie I have no idea who hosts it and/or how legit they are) but I assume (perhaps naively?) that it should be ok...!?

It seems to get regularly updated too which may be a handy thing...

Only thing is whether it may be best to try to install to the GitLab appliance, or to install to Core... Either way TKLBAM will need a bit of tweaking to make it work right (to make sure all the repos etc are backed up).

Hi guys, sorry for not helping right away, I'm just full right now, but I talked last week to Alon about this thread. He commented that Gitlab is being installed from a tarball, so it won't be upgradable like it is. I think he knows that this may not have been the best way to install for the appliance, considering the awesome rhythm of releases the gitlab team is able to produce. 

Anyway, I would need time to play with this which I don't have this week but I think I'll be able next week to take a look. Meanwhile, you can take a look at my original TKLPatch for this appliance (used as a base for the official one):

https://github.com/adrianmoya/tklpatch-gitlab

I hope it helps, if not download tkl-core and apply the patch. Once finished, the result should be upgradable using the official docs. If it goes well, I'll see if I can convince the TKL guys to change this particular appliance.

I have done it (sort of...)!

It's perhaps a dirty way of doing it, and I'm certainly not saying it's the best way - but it works! It basically reinstalls GitHub from scratch (with a fresh DB as well). I have included some lines that backup the old GitHub install folder and DB as as I have intention to try to update my GitLab server (that includes data) but haven't got there yet. I also thought then at least if someone doesn't read all this and does it on their existing server (with data) then all wouldn't be lost...

Ideally it'd be nice to create a TKLPatch of this, or at least a nice script that you can download and run, but until then...

Note: I am yet to try this on a server that already includes data. I hope to refine this so it will work with existing data, but for now (unless you want to build on my work) I suggest that if you have existing data, run this on a clean install and then migrate your data across (I haven't tried it but I have read about it on the GitLab wiki).

What it does:

• updates package lists and upgrades all GitLab dependancies
• backs up the DB
• deletes (drops) the DB and recreates an emplty one
• backs up the github folder (actually renames it)
• Then does a more-or-less clean install (from the stable GitLab GitHub repo)

You will need your MySQL root password handy (and put it in the 3 times you will be asked).

apt-get update
apt-get install -y wget curl gcc checkinstall libxml2-dev libxslt-dev libcurl4-openssl-dev libreadline6-dev libc6-dev libssl-dev libmysql++-dev make build-essential zlib1g-dev libicu-dev redis-server openssh-server git-core python-dev python-pip libyaml-dev postfix libpq-dev
mysqldump -uroot -p -c --add-drop-table --add-locks --all --quick --lock-tables gitlab_production > gitlab_sql_dump.sql
mysqladmin -uroot -p drop gitlab_production
mysqladmin -uroot -p create gitlab_production
cd /home/gitlab
sudo -u gitlab mv gitlab gitlab-old
sudo gem install charlock_holmes --version '0.6.8'
sudo gem install bundler
sudo -u gitlab git clone -b stable https://github.com/gitlabhq/gitlabhq.git gitlab
cd /home/gitlab/gitlab
sudo -u gitlab cp config/gitlab.yml.example config/gitlab.yml
sudo -u gitlab cp /home/gitlab/gitlab-old/config/database.yml config/database.yml
sudo -u gitlab bundle install --without development test sqlite postgres  --deployment
sudo -u gitlab bundle exec rake gitlab:app:setup RAILS_ENV=production
sudo -u gitlab bundle exec rake gitlab:app:status RAILS_ENV=production
sudo -u gitlab cp config/unicorn.rb.example config/unicorn.rb

And that should do it...!

Now start GitLab:

service gitlab start

And log in... Note that when logging into the WebUI you will need to use the default GitLab login credentials:

admin@local.host
5iveL!fe

Warning: DO NOT RERUN THE FIRSTBOOT SCRIPTS! It will break GitLab!

The next thing I plan to try is just migrating the DB (rather than dumping it and recreating it). It would also be nice to preserve the intial log in details (that you already set up). It'd be super nice to get it working with existing data... (which will rely on not destroying the DB). I'd also like to adjust the firstboot script so it's not destructive.

I first found TKL and GitLab in the list of Proxmox containers. It came with GitLab 8-17. When I found some bugs that annoyed me, I began looking to upgrade.

I am upgrading from source. There are many problems with this but I am documenting them and the workarounds needed.

These scripts I have written are specific to TKL GitLab 14 running GitLab 8-17-stable. 

Upgrading to 10-8 works. Currently, I am working on getting 11-4 working.

https://gitlab.com/RoyceTheBiker/upgradetklgitlabct

I made the decision to use TKLXCore + GitLab Omnibus and have never had an issue. Press the button to upgrade and it is all done for you. That is not the case with a GitLab VM built from source...more complicated upgrade / lifecycle path.

GitLab has changed repeatedly and significantly over the years. I knew that would be the case when I first deployed 3 years ago so I did not go with the TKLX GitLab VM which is based on source and has a more complicated upgrade path if you are not a Ruby on Rails expert.

The only downside to a TKLXCore + GitLab Omnibus is the TKLBAM configuration needs custom configuration because the TKLBAM delta is built from the TKLX-Core image vs. the TKLX-GitLab image so it is a bigger delta without custom TKLBAM configuration..

Looking back on what my upgrade path was like, I would not recommend upgrading TKL GitLab. 

The TKL VM is a great way to introduce people to GitLab, but if you are serious about using it and you don't want it to consume all your time, then Omnibus is the way to go. 

I don't think there is an easy way to switch to Omnibus because it requires changing data engines from MySQL to PostgreSQL. 

I personally will stick with the TKL now that I have learned so much about how it works. Also, my upgrade path changed the data engine to MariaDB and I like what that community is doing. 

Hey Jed...can you elaborate on why DB is an issue. You support a PostgresQL appliance (https://www.turnkeylinux.org/postgresql ) so I would be concerned if this is an issue...just saying :-)

Regarding your opinion about overkill...as a personal Git Gui...well yes...that's not what GitLab is useful for. It is useful where there are 2+ users. So for TKLX, your software would be better managed from GitLab.com than GitHub.com or, better yet a (Omnibus-powered) AWS-hosted GitLab. Now there's an idea...full C.I....killer.

I have my opensource projects on GitLab.com and I manage an AWS-hosted GitLab for a client. Been running both for a couple of years now...no issues. None.

For desktop have a look at GitKraken or just manage Git from your favorite IDE.

@Royce...you might consider just doing an export / import to switch to an Omnibus install. I'm not sure you would lose anything in the transition. Just a thought.

To make a decision about having / not having a git repository VM in the TKLX library has much to do with the demands of the TKLX audience...for which I cannot speak, obviously.

So what would a TKLX audience want to do with a git repository!

With GitLab.com and GitHub offering free public and private hosted repositories it is tough to put up any business case for a self-hosted git repository VM other than for privacy, educational, or intellectual property reasons .

The challenge is lifecycle management.

If a VM lifecycle management cost is too high then the TKLX company and TKLX community cannot cost-effectively assist someone deploying that VM in a critical use-case. A shared development repository can certainly fall into the critical use-case category (when it goes down you need it fixed...now).

In a SaaS world, the continued use of self-hosted VMs is typically for cost, privacy, or IP management reasons. There are some other reasons but it would require more time than I have in this post to get into (like ownership of business rules, business knowledge, business processes, commercial competition visibility, etc).

But anyone who takes on the burden of lifecycle managing a TKLX VM (or any supplied VM for that matter) has to decide if the convenience cost of a quick install is outweighed by a massive lifecycle management burden.

GitLab falls into this category.

Although a GitLab VM is arguably no more or less complex than and Odoo or OrangeHRM VM, those are applications and are, for the most part, self-contained.

A Git Repository is actually the centre of a web of interconnected parts. Simple repository...complex interconnection network. Complex repository...simple interconnection network. Gitea is the former, GitLab is the latter.

The Gitea comparison looks good on paper but...

a) GitLab has an integrated end-to-end model (https://about.gitlab.com/direction/product-vision/ )

b) GitLab is Issue-Centric. Everything starts, continues, and completes w.r.t. issue. This is different than Gitea. Gitea has issues but is not issue-centric. If you want a reasonable head-on-head comparison it would be GitLab vs. Trac. For value-for-effort I would take GitLab over Trac any day. GitLab is an Issue-tracking system with an integrated issue-resolution model. There is nothing like it.

c) Take a look at GitLab's C.I. integrated support for Docker / Kubernetes. Brain-dead simple. I have a client that is using a C.I. runner to connect with their CRM system via API because the short Python script they wrote to do the job is in the repository and, well, they only needed a few button presses to deploy a scheduled daily on-demand container-based job-run via VULTR.

I don't believe a GitLab-based TKLX VM should be in any other form than an Omnibus install. Yes...this makes it different from other more conventional open-source based TKLX VMs but it is the only way to align this VM's post-install lifecycle management cost profile with the post-install LCM cost profile of, say, a LAMP VM.

Certainly a Gitea VM would align better with the other VMs from an install / post-install LCM profile so might be a better candidate for the TKLX company to manage rather than GitLab.

And for the record, discounting the usual system configuration issues you would expect with any Linux VM-based product, this is the upgrade script I run once a month after they release:

apt-get update
apt-get install gitlab-ce

What's my lifecycle burden for a Gitea VM. Just saying :-)

Your call :-)

I assume you will use the TKLX Core? (So, using the Omnibus Postgresql install and not installing one ourselves.)

Until I dig in and start work on it, I'm not 100% sure exactly how it will go. As far as teh buildcode goes, it won't be a rebase back on Core (it will be a continuation of the current GitLab buildcode repo). But as all appliances are essentially based on Core anyway, it sort of will be based on Core. Sorry, that probably makes limited sense...

In an effort to clarify my last paragraph; the new build use all the contents of the GitLab Omnibus package. E.g. it will include git and Postgres from the Omnibus package (rather than from Debian repos). I think that answers your question better!

If you feel you would like some configuration changes to the Omnibus installed components (NGINX and POSTGRESQL) you might consider doing post-install configuration & reboot script so we can more easily reproduce an out-of-the-box GitLab equivalent.

The way we would generally do that, is that any (new) defaults would be provided via an overlay or (preferably) tweaked via a conf script. But I anticipate that any changes we make would only be changes to GitLab defaults, not radical rewrites or anything. So working on the assumption that it would be nothing particularly significant (i.e. stuff that a "reasonable" somewhat advanced end user may do), I wouldn't expect any changes that we make would have any significance over and above what GitLab would come across with any end user installed system. Thus should not have any impact on any bug reports and/or support via GitLab.

Having said that, assuming that the Omnibus package is built in a sane way (and the defaults are included in the package as text files, then copied into place at install time), documenting how to get the original defaults from the Omnibus package should be pretty straight forward.

The main benefit I am hoping to gain from this exercise, if possible, is a working / optimised TKLBAM. I have not yet sorted out TKLBAM to do it myself. I expect that a base image on the TKLX server is required to really benefit from TKLBAM's incremental backup architecture?

Yes, we will be creating a new TKLBAM profile for the updated appliance (as we do anyway for each release). Moving to the Omnibus install will have the advantage that it should actually work a bit better than the current GitLab TKLBAM profile.

Based on experience to date, post-omnibus-installation configurations relevant to the TKLX VM admin console / wizard are as follows: 1) Configure GitLab settings to support AWS as external data-store for large data items 2) Confiure GitLab settings for Mattermost connectivity 3) Configure SSL Certificates 4) Configure a RAM-disk swapfile so GitLab does not trigger the dreaded OOM-killer resulting in 500 errors.

Hmmm, I'm not sure that we would be configuring too many of those things, initially at least. We could consider adding them as confconsole plugins though. Are these initial options within some sort of GitLab "install/first-run wizard" or something? TBH, I've never seen mention of most of those before...

Re specifics:
1. You mean like git-lfs right? AFAIK git-lfs should already be an option OOTB?! And other than perhaps dependencies (boto?) , I would imagine that it would be relatively minor config required. If you have further info/insight to share in that regard, please do so.

2. Again, isn't that something that comes OOTB? AFAIK the Omnibus package includes Mattermost support already? (Although, perhaps disabled by default?) At least, that's what my recent research lead me to believe...

3. As our implementation is webserver agnostic, I wouldn't expect this to be an issue. If you want a common cert for GitLab, Webmin and Webshell, then you could use the Confconsole plugin we provide. Otherwise if GitLab has some other implementation built in, then using that should not cause any issues. I would potentially expect one to override the other, but I wouldn't expect that to be problematic, although I guess we'll need to see how GitLab do it. And obviously it'll need testing.

4. In my testing (admittedly nothing compared to your first hand experience) a larger server with more RAM is a far superior option on AWS than adding swap. It gives a far superior user experience (RAM is tons faster than any harddrive, even SSD) and as AWS charge for IO (beyond the threshold that I forget OTTOMH), if swap is being used heavily, you may not even be saving any money!

OTOH I guess if you are trying to squeeze every last bit out of a server that is really too small for it's peek usage, then it might be a good thing. I am somewhat hesitant to set that up by default, although again a confconsole plugin could be an option? Having said that, I do note that GitLab recommend 2GB swap, even when using (the recommended) 8GB min RAM so perhaps we should consider it...?! (I think I prefer my lightening fast Gitea server which uses about 256MB RAM! :-p) FWIW all the reading and reviews I've seen recommend a t2.medium as a minimum for GitLab on a single AWS EC2 instance (even for a single developer). Again I'd be interested in your experience.

I'm hoping to get onto this ASAP. Once I have something I am happy to share it, and would love some feedback on it. Although I won't have an AMI, only an ISO initially.

My comment about using Core was just meant to say that the VM should be Core + Omnibus and not Core + Posgresql + Omnibus.

Regarding the config options 1-2...these are not GitLab OOTB. They are all ready-to-go but you need to do a few things to enable them. I just thought I would put them on the radar for the VM confconsole / wizard. E.g. Mattermost needs a unique domain...could be prompted for in the confconsole / wizard.  AWS requires some credentials and bucket info to be added to multiple places in config files...again...could be prompted for in the confconsole / wizard.

Regarding option 3...the SSL just needs to be sorted. There are a number of places SSL certs need to be added to GitLab config files. Deciding to rely solely on TKLX LetsEncrypt + auto config file updates vs. enabling GitLab native LetsEncrypt is the only thing that needs a bit of thought.

I consider swapdisk to be mandatory. The issue is that GitLab like most (if not all) Linux apps does not moderate its RAM usage. No matter how much RAM you add you risk an OOM kill. The main culprit is C.I. jobs and artifacts. Because jobs can be long running you can have an OOM kill situation on a live system with no reasonable way of addressing it. The RAM disk is insurance. Additionally, AWS has economic flexibility on disk but not RAM. You have to unnecessarily jump an insance size to get more RAM. A decent size GitLab works fine on a Medium T3. Doubling the cost to a large instance is an unnecessary cost for a C.I. triggered short-term RAM overrun. I have already implemented and documented the process for adding a RAM disk. It is quite simple actually (after I did all the research of course).

You bring the VM build knowledge and I will bring the GitLab knowledge. Between the two of us we could have the first pass VM in place within 24 hours and then go from there to decide how much additional effort would be required for release.

I'm ready when you are :-)

Excellent...I am available to invest time most of next week :-)

Can we set up a phone call? I would like to learn the process of building a TKLX VM, configuring TKLBAM, and customising confconsole. I am happy to do some coding and testing. And I have documented all the configurations we will need. I would like to document the entire process required to build this VM.

FYI- I need to upgrade my client from an M1 Medium to a T2 Medium so this is perfect timing. And since I will need to migrate using Import Export I can document the migration process as well.

Regarding your swapfile question...I used a swapfile. I considered a swap partition a future consideration.

Swappiness should be 10. We can't wait until 100% RAM utilization and risk an OOM kill. 10% is an adequate buffer based on my analysis of previous OOM kills that occured on my GitLab system.

Swapfile / Swap-partition references I short-listed:

- how-do-i-configure-swappiness

- setting-swap-partition-size

- how-to-configure-virtual-memory-swap-file-on-a-vps

My Instructions:

1) Configure Swapiness
- sudo vi /etc/sysctl.conf
- Add the following line:
    vm.swappiness = 10
- You can test this using the following BASH command:
    cat /proc/sys/vm/swappiness
- You can also change swappiness at runtime using the following BASH command:
    sudo sysctl vm.swappiness=10
    
2) Configure 2GB swapfile (blocksize (a.k.a. bs parameter) should not be too small or too large from an efficiency perspective)
    - cd /
    - dd if=/dev/zero of=/swapfile bs=2048k count=1000
    - mkswap /swapfile
    - swapon /swapfile
    - EDIT /etc/fstab and add the following line so that the swapfile is recreated on reboot:
        /swapfile       swap    swap    auto      0       0
    
    You can check the swapfile using
    a) swapon -s
    b) free

NOTE: GitLab VM should be defaulted to 20GB disk space and recommended minimum instance size is T2 / T3 Medium.

Having used VMs for over 20 years, back in 1998 when a small company used GPL code to create the kernel accelerator module and gave rise to a new generation of virtualization, I am a big fan of VMs.

That being said, if you are not changing OS or architecture, LXC is better in every way.

• Faster, like way, way, way faster
• Less overhead on CPU
• Closer to RAM
• Direct hardware access (not emulation)
• Scales on the fly (adjust resources live)

On the topic of swap, my next home system is going to be either Threadripper or Epyc with multiple M.2 so I can use NVMe for swap. This will effectively give me a terabyte of slow RAM. 

At work we are going to start using HP G10s with Epyc and Optane. These systems are so insanely fast that just one G10 will be able to replace eight of our existing G8 servers, or an entire datacenter of G5s.

I love tech!

And we should change to a new thread because this is so far off topic.