Upgrading Gitlab

[atomaka]

@sbadia are you using this in a production environment at all or is your primary purpose for development using vagrant? It appears that the code is only for a fresh install process. If that's the case, any thoughts on implementation? I can't really think of a way other than providing a second server.pp (upgrade.pp) file built around the upgrade process.

I'd love to hear other thoughts before I look to start implementing this.

[sbadia]

Hi Andrew, yes I use it in production, by cons I made ​​the updates manually (yes shame on me), and I will update therecipes with a pre cmd (pupppet --noop). I am willing to help for this feature !

Thanks !

[atomaka]

I'm still not even sure where to start with this even in the simplest case. All of my puppet code to this point has been for setting up clean servers. The standard upgrade process is pretty simple:

• Download GitLab source
• Download gitlab-shell source
• Bundle commands for install and migration
• Update config scripts
• Update init script

But with the pace of GitLab development, there are frequently dependency changes that we would at least need to perform checks for.

To start, how can we determine the currently installed version of GitLab? Can we read a file and compare string or do we need to include a version file and run a diff to find the current version?

[mc0e]

I think this is probably a good thing to raise in the puppet channel on IRC. There's a lot of good advice to be had there.

In general, the puppet language is not designed for describing transitions of the state of a system. It's whole philosophy is that you describe how the system should be, and puppet makes it so. I expect that the upgrade process should be mostly described by a script or system of scripts outside of the puppet language. That script is substantially simpler than it might be though if the prior state of the system conforms to a known puppet configuration.

[spali]

Hi just found this issue and had an idea... gitlab upgrades are well described in a few simple steps in the upgrade guide, one per release. maybe not the best approach, but a easy way would be to put these upgrade commands in a script per release. then puppet could read the VERSION file in the gitlab directory and just execute the update script for the next release till the defined target release is reached.... would maybe give a bit a big chain of scripts and dependencies but maybe this would work ... then only a upgrade script per release must be build in the module. since the steps are almost the same, this would have some improvements...

[atomaka]

@spali Mainly, I am not sure how we could manage to do multiple upgrades in a single puppet run.

I'm hoping to take a look at this next week and will probably start off with only handling upgrading from one release behind.

[spali]

A possible approach would be: single scripts separated by upgrade steps upgrade_51, upgrade_52 etc. Then a "master" upgrade script which get the target release by an argument (51, 52, etc, and latest) The upgrade script could be made without any hard coded dependency to a specific release. It just reads all available upgrade step files and execute these scripts in the right order till the target release (by argument) is reached. This would allow to do multiple upgrades in one puppet run and also you can define a release to stay on in puppet or go to the latest. Similar to "package" in puppet.

This would separate the release specific stuff to the release specific upgrade script and the general logic of using this scripts including a good error handling in the "master" script.

The best would be if at least the release specific upgrades scripts would be maintained in the gitlab repo. Maybe also the master upgrade script, because this is theoretical a part of the application in my eyes... but I don’t know if gitlab want such scripts in the repo and want to maintain it. One argument would be, they could have a easier upgrade documentation and the upgrade would be non release specific in the document. Don't know how open minded they would be with such a requirement :)

[atomaka]

@spali I understand the general process. I'm just confused how it could be implemented in actual Puppet code. What you've described is a basic loop, which there still isn't official puppet support. The each keyword is available in 3.2, but only by manually configuring your puppet installation to use the "future" parser. PuppetLabs notes that they won't release this live until a major release so it is safe to assume that it will break other functionality. Requiring it enabled would likely make puppet-gitlab incompatible with a large number of modules.

Did you have a method in mind to be able to accomplish this?

[spali]

I meant to do the loop in a script. Puppet has only to read the currently used gitlab version. If it is not the configuered one, puppet invokes only the upgrade script with the defined target version as argument and the script does the rest.

[mc0e]

There's a couple of different upgrade approaches possible. One approach is to upgrade the server in place. Another is to fire up a new server virtual machine, and import the data from the old one. Firing up a new server won't suit everyone, but it has the advantage that you can test the new setup before tearing down the old one.

So, is there a good process for transferring the data across to a new server instance, and can we puppet-ise the data import process?

[mc0e]

In terms of describing an upgrade process in puppet, it's not something that should be in puppet's .pp code. It's contrary to the nature of the puppet code, which describes the desired state, not the procedure to get there. Puppet lets you determine the order in which you enact assertions of system state, but it doesn't give you modelling of different states of the same resource at different points in the process. You can sometimes kludge it, but it's generally a bad idea.

What I'm thinking would be to have the puppet code express the desired system state, and accompanying library code, presumably in ruby that handles the transition to the desired state. eg have a lib/puppet/provider/package/gitlab.rb

It's a shame we can't just refer this to the appropriate apt or rpm package like 99% of other software in the linux world, but that being the bit that's missing, it seems sensible that it's at that point we want to insert our own code to bridge the gap.

[wolfspyre]

I'm of the opinion that an upgrade script would be most beneficial if developed as a shell script, and contributed upstream. If upstream will adopt and nurture a consistent means of upgrading from version to version, puppet could be coerced to perform the update when necessary, and other gitlab users have a clean means of upgrading

Easier said than done, however

[igalic]

With #99 and #86 this may be more in reach than before

[atomaka]

If everyone was up to date and only running an upgrade one at a time it would be relatively simple. Unfortunately, this is often not the case. Determining a version dependency tree and upgrading incrementally is a bit more difficult coupled with the fact that installation instructions often change from version to version (ie. Unicorn -> Puma -> Unicorn).

[atomaka]

Perhaps we'll be able to leverage this for minor versions?

[sbadia]

Upgrade script released in 6.4 (script/upgrade.rb)

[andyleejordan]

If you've manually upgraded using the script, the next Puppet provision will mess it up by bringing the repo back to the version specified in the module. You'll want to set the variable $gitlab_branch, but also check if the upgrade script left any uncommitted changes.