Minimize steps to run an upgrade without post-deployment migrations
As suggested in: !3562 (comment 221361092)
From an omnibus-gitlab perspective, it would be nice to move towards a world where we don't need
/etc/gitlab/skip-auto-reconfigure
.I'm not sure if we run
sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true apt-get install gitlab-ee
if that passes on. As an alternative, we may want to add an attribute togitlab.rb
for skipping post deployment migrations.
Current status
At the moment the user has to:
- make sure
apt update && apt install gitlab-ee
does not run the post-deployment migrations by:- disable auto-reconfigure by creating
/etc/gitlab/skip-auto-reconfigure
, or - add
gitlab_rails['auto_migrate'] = false
togitlab.rb
- disable auto-reconfigure by creating
- run the upgrade
- do the migrations (excluding post-deployment migrations) by running:
sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true gitlab-ctl reconfigure
These steps are taken, only to avoid the post-deployment
migrations. So what if we could run a apt update && apt install gitlab-ee
that does everything, except for the post-deployment
migrations.
(rejected) Proposal
Most boring and simple solution would be:
sudo SKIP_POST_DEPLOYMENT_MIGRATIONS=true apt-get install gitlab-ee
But we first have to check if this environment variable is properly propagated to reconfigure
?
(accepted) Alternative proposal
If the above proposal not works, would it be possible to introduce a setting in gitlab.rb
:
gitlab_rails['skip_post_migrate'] = true
# and for Geo secondary nodes
geo_secondary['skip_post_migrate'] = true
This proposal even might be preferred because:
- no more use of a quirky command
- more transparent what happens
Challenges
- I've been working on this in !3740 (closed), but I realized this might not work correctly when skipping one or more minor versions. So when the upgrade process detects releases are skipped (I think it does the same to see if it can do zero-downtime upgrades) it should ignore the
gitlab_rails['skip_post_migrate'] = true
setting. - Documentation-wise this might be a problem. From the version that supports this new settings the instructions for zero-downtime upgrades are quite different, but we still need a way to document the old process for people to follow for lower versions.