I have a question about upgrading from 15.11.13 to close to the latest (17.x).
I can’t quite figure out just what stops I need to make and since I have a couple large instances I don’t want to carve out a lot of testing time and downtime at stops I don’t need.
This shows a stop at 16.1.6 and then to 16.3.7 and so on.
The official docs at Upgrade GitLab | GitLab seem to have some guidelines but it’s not really defined. 16.0.8- Under 30k users so that’s fine but what is a “large” amount of ci_pipeline_variables ?
I don’t have the registry enabled at all (so no npm packages) but does 16.1.6 do something else with the above?
16.2.9 is kind of the same as 16.0.8, etc.
Just curious what actual stops I would really need to do.
You have to follow the path as suggested by the upgrade tool. That means upgrading to 16.1.6, waiting for background migrations to finish, then start the next upgrade on the path: eg 16.3.7, then 16.7.7 and then 16.11.1 - ensuring after each version upgrade to again wait for background migrations to finish.
The larger the Gitlab installation, the longer you will have to wait for background migrations to finish. You have to go through the versions mentioned above, because they include specific items that need to be completed and run. You cannot skip an upgrade that is listed on the upgrade path. So no, you cannot install 16.2.9 because it’s not the same as 16.0.8 nor is it the same as 16.1.6.
- I’m well aware I need to follow the path as I’ve done so since the 11.x releases.
- I cannot tell if my first link is an official Gitlab site or not (I use it well but the domain name is not the same as normal gitlab so unsure if it’s too “official” or just a hobbyist run site.)
- I do follow the guide and know background migrations take time, etc. but the issue is the official documentation at the 16.x range is not at all clear.
GitLab 16: 16.0.8 (only instances with lots of users or large pipeline variables history) > 16.1.6 (instances with NPM packages in their package registry) > 16.2.9 (only instances with large pipeline variables history) > 16.3.7 > 16.7.z > 16.11.z.
Looking at that- do I need to stop at 16.0.8? Who knows because it doesn’t specify what a "large pipeline variable history is.
16.1.6? Is that ONLY for instances with NPM packages or like the first link I sent is it a required stop? This seems to suggest it’s only for instances with NPM packages in the registry.
16.2.9? This seems to say the same thing as 16.0.8 but again doesn’t detail what a “large” amount even is.
The rest are normal and what Gitlab has traditionally done- ie. do 16.3.7 (or its latest patch), 16.7.x latest patch in that minor branch, etc. etc.
Hello Blueduckdock7888! I just completed an upgrade from 12.x to 16.10
The upgrade tool is semi-official; it’s the Gitlab Upgrade Team’s tool, and it’s on it’s own domain. I’ve used to same for my upgrade over the last few months.
On the upgrade tool, you can click the tab for all the info, as you may have already surmised:
That information is the cumulative changes that will take place when you upgrade to that listed upgrade stop. Many may not apply to you, and some of the information is poorly worded - and makes it seem like you need to upgrade to intermediate steps in between the stops, such as the example you pointed out “Maximum number of active pipelines per project limit” issue that was resolved in 16.0.
Typically, however, those database migrations and patch rollups are tested to work to the required stop point.
Since you’re on omnibus, the upgrade tools should get you there; I followed exactly this process last month.
If you’re in the envious position of your gitlab-ce instance being a virtual machine, just take a snapshot before the upgrade if you’re extra nervous.
As a heads up, I did run into one issue pretty late in the upgrade path on 16, that was able to be resolves with some gentle massaging of the database. YMMV:
Good luck!
Many thanks @joel.mclean and @iwalker .
I appreciate the clarification around it. Like I said, this was the first time I saw this much ambiguity in the verbiage (and while the reliability of upgrades has gone up since 11.x, I still am wary of issues like your latest one Joel.)
And yes- I do snapshot when I can but I have some instances that are on baremetal and thus can’t be snapshotted (or at least I do so with LVM tools as a fallback.) But hey- measure twice, cut once right? Thanks again.
2 Likes