Separate infrastructure creation layer and GitLab deployment layer

Overview

In its current form, the Orchestrator performs the following

  1. Spins up the infrastructure required to support a specified scaled architecture
  2. Installs GitLab on each node and configures each node to have a specific role

Currently, the Orchestrator supports deploying on GCP as an MVP.

Concerns to address

In a call with @ronanoconnor, a couple of concerns were raised from a Support perspective.

  1. If the Orchestrator spins up infrastructure, customers might expect Support to help them troubleshoot issues with the infrastructure. This is beyond the scope of what Support would normally cover
  2. Customers might already have their own scripts to spin up infrastructure
  3. Often there is a different team that is responsible for setting up infrastructure. Once the infrastructure is created the application admin team would take over the deployment and configuration of the application
  4. Many of our largest customers run GitLab on prem on their own hardware and they want full control over setting up the hardware.
  1. Support is very interested in having customers conform to more standardized architectures for GitLab and would like to see the Orchestrator project prioritize enforcing the reference architectures.

Proposal

  • Ensure that the Orchestrator is modular enough that customers can use it to install and configure GitLab in a scaled environment without using the Terraform piece to set up the infrastructure. This will also mean that an early release of the Orchestrator can be used in any environment, including on-prem physical servers.
  • Ensure that the module for installing and configuring GitLab can easily plug in to existing infrastructure deployment automation provided by the customer
  • The Terraform piece to spin up the infrastructure will be a big time saver for internal GitLab teams, and also for some portion of our customer base, so it will continue to be an important piece, but it will be helpful to separate the Orchestrator out into two layers 1. The infrastructure creation layer, and 2. The GitLab installation and configuration layer
  • In end user documentation, emphasize the GitLab installation and configuration layer above the infrastructure layer, or provide clear messaging that Support is not responsible for troubleshooting the infrastructure that gets created by the tool.
  • If we are emphasizing the GitLab installation layer over the infrastructure layer, how do we enforce the architecture and specifications recommended in the reference architecture? One suggestion by @ronanoconnor was to have a check script that makes sure each node has the right specs before installing GitLab.

Closure Summary

Closed in favor of breaking out each abstract concept into its own issue for discussion to maintain clarity and allow us to iterate more efficiently.

Edited by Robert Marshall