Wrong migrate/restart order on some upgrades
Recipe: gitlab::unicorn
* service[unicorn] action restart
- restart service service[unicorn]
Recipe: gitlab::sidekiq
* service[sidekiq] action restart
- restart service service[sidekiq]
Recipe: gitlab::gitlab-rails
* execute[clear the gitlab-rails cache] action run
- execute /opt/gitlab/bin/gitlab-rake cache:clear
Recipe: gitlab::database_migrations
* bash[migrate gitlab-rails database] action run
- execute "bash" "/tmp/chef-script20150723-10971-fz3vag"
Recipe: gitlab::ci-unicorn
* service[ci-unicorn] action restart
- restart service service[ci-unicorn]
Recipe: gitlab::ci-sidekiq
* service[ci-sidekiq] action restart
- restart service service[ci-sidekiq]
Recipe: gitlab::gitlab-ci
* execute[clear the gitlab-ci cache] action run
- execute /opt/gitlab/bin/gitlab-ci-rake cache:clear
Recipe: gitlab::database_migrations
* bash[migrate gitlab-ci database] action run
- execute "bash" "/tmp/chef-script20150723-10971-1gjemia"
Running handlers:
Running handlers complete
Chef Client finished, 36/242 resources updated in 94.716182965 seconds
gitlab Reconfigured!
What is wrong here is that the Unicorn/Sidekiq services restart and load the old DB schema from the database, because the migrations run after the restarts.
@marin I think this because in recipes/gitlab-rails.rb and recipes/gitlab-ci.rb, we render all templates before triggering migrations. So if there is a template change during an upgrade the order gets messed up. I think maybe we should put the remote_file
resource that triggers DB migrations before all the template
resources in the gitlab-ci and gitlab-rails recipes. What do you think @marin ?