Simplify Geo upgrade process
This issue will be broken down further for %12.2 - in %12.1 we will focus on product discovery and to ensure that we fully understand the steps that need to be taken to simplify the Geo upgrade process! The deliverable for %12.1 is the plan on how to get there, not the full implementation!
Problem to solve
Currently, updating Geo requires updating GitLab itself on every primary and secondary nodes, followed by two manual steps:
- Updating the tracking database on secondary node(s)
- Testing primary and secondary nodes + version checks
These steps are manual and need to be executed on each node individually, which can be cumbersome. There should be as little effort as possible for customers to upgrade to the latest version of GitLab and Geo
Intended users
Further details
As a systems administrator, I would like to update GitLab on my primary and all my secondary instances in the same way, so that I don't have to worry about different configurations.
As a systems administrator, I would like to be informed automatically if a problem with Geo occurs during the upgrade, so that I don't have to remember to check versions manually.
As a systems administrator, I would like database migrations to be run automatically when needed, so I don't have to remember to check manually.
Overall, I would suggest that the desired end state is that the GitLab update mechanism detects if GitLab is run using Geo in primary or secondary mode and performs all additionally steps automatically, if at all possible. This would mean, that Geo upgrades require no manual intervention by system administrators.
If this is not possible, the documentation needs to clearly reflect all necessary steps.
Proposal
Implement the above user stories individually.
Permissions and Security
N/A
Documentation
Updates are required to: https://docs.gitlab.com/ee/administration/geo/replication/updating_the_geo_nodes.html
Testing
Increased automation often requires more testing in order to establish that operations succeeded.
What does success look like, and how can we measure that?
Success means that the number of additional steps to update GitLab including Geo (both in primary and secondary installation is significantly reduced. Currently, two steps are needed. Success would be 1 or 0 steps.
What is the type of buyer?
N/A