Slim down the upgrade path
Problem Statement
teamDelivery is working on a few items to contribute toward stability when it comes time to upgrade the GitLab application when Cells comes to SaaS. As a result, we are looking at what tooling is responsible for specific aspects. In the case of Cells, some of the Environment Automation team's tooling, specifically, Instrumentor, which consumes GET, will be leveraged. There are at least a few goals:
- Reduce the time it takes to perform upgrades
- Reduce the potential for which configuration changes may sneak in alongside GitLab upgrades
- Eliminate dependencies on external systems required to run the GitLab Environment Toolkit
Currently, GET is called upon via Instrumentor during its configure
stage. Reference. This process currently takes over 45+ minutes. GET is responsible for approximately 10-15 minutes per site (when Geo is enabled) on the dev_v2
reference architecture. Work is underway to shrink various orchestration items that are unrelated to GET. This issue is to spin up a discussion around seeing what fits the model for GET, if anything.
Since Instrumentor fully orchestrates a deployment, we should be able to more quickly see gains by changes in this area. However, if there's room to meet some of the goals above, we can further improve Instrumentor, especially if this is valuable for customers as well. Instrumentor handles this orchestration in a phased approach as described in the following diagram.
flowchart LR
A(configure stage) --> D[custom stuff]
D --> E[GET configure region primary] --> F[GET configure region secondary]
F --> G[GET configure geo] --> H[database migrations]
Our goal in this issue is to address the following:
GET configure region primary
GET configure region secondary
Reference Prior Conversations
- Our first attempt at this work: !1281 (comment 1846520119)
- A really great precursor to this issue: gitlab-com/gl-infra/delivery#20067 (comment 1902951854)