Define a scope for features and components that can constitute a minimum GitLab instance and used for developing a proof of concept for GitLab Operator.
Propose a deployment and configuration model for the minimum GitLab instance that does not depend on GitLab Chart.
Acceptance Criteria
Scope of minimum GitLab instance id defined. Which components and features are included and which are not.
A deployment manifest draft for the defined scope above which shows the orchestration and configuration of components. This can be a Docker Compose file or a Kubernetes manifest.
Timebox
Limit the exploration to maximum of two days. This is not due date but the time to make a decision on the path forward and the feasibility of the solution.
While I am not sure we have these fully documented in a written form, we can reference the example configurations that the Helm chart include within their examples (https://gitlab.com/gitlab-org/charts/gitlab/-/tree/master/examples) as minimum instances. From there we can confirm / acknowledge these as acceptable with the QA / platform team(s).
ObjectStore (using GCS) with the following preparations:
Create a GCP ServiceAccount and GCS bucket and allow access:
GCP_SERVICEACCOUNT_NAME="${GCS_BUCKET}-sa"GCP_SERVICEACCOUNT="${GCP_SERVICEACCOUNT_NAME}@${GCLOUD_PROJECT}.iam.gserviceaccount.com"gcloud iam service-accounts create "${GCP_SERVICEACCOUNT_NAME}"\--display-name"GCS access for ${GCS_BUCKET}"\--description"Created by ${USER} for testing ${GCS_BUCKET}"gcloud storage buckets create "gs://${GCS_BUCKET}"gsutil iam ch \"serviceAccount:${GCP_SERVICEACCOUNT}:roles/storage.objectAdmin"\"gs://${GCS_BUCKET}"
Create a Secret with GCP ServiceAccount credentials:
Shared secrets Job creates all of the Secrets, including for the components that are not enabled. The Secrets are shared between components (hence "shared secrets") but TLS certificates aside, a minimal instance 3-4 Secrets are needed.
There are two separate ConfigMaps for Puma and Workhorse.
For installing and upgrading a minimum GitLab instance an Operator must manage:
4x Secrets (excluding TLS certificates for Ingress)
5x ConfigMaps
2x Services
2x Deployments
1x StatefulSet
3x PodDisruptionBudgets
2x HorizentalPodAutoscalers
1x Job
1x Ingress
In total 21 objects. As a starting point, we can use the source or rendered template of these objects in GitLab Chart. Although GitLab Operator V2 may choose a different approach to apply these objects and does not necessarily follow GitLab Chart model.
Hossein Pursultanimarked the checklist item Scope of minimum GitLab instance id defined. Which components and features are included and which are not. as completed
marked the checklist item Scope of minimum GitLab instance id defined. Which components and features are included and which are not. as completed
Hossein Pursultanimarked the checklist item A deployment manifest draft for the defined scope above which shows the orchestration and configuration of components. This can be a Docker Compose file or a Kubernetes manifest. as completed
marked the checklist item A deployment manifest draft for the defined scope above which shows the orchestration and configuration of components. This can be a Docker Compose file or a Kubernetes manifest. as completed