GitLabCore reconciler

Status: Implemented Issue: none Parent: none

Goal

An administrator describes a GitLab instance in one GitLabCore resource, and the Operator keeps the cluster in line with it. The Operator deploys the GitLab chart without Helm release storage and without widening what a writer of the resource may do.

Child specs:

• Configuration: how the structured fields configure the instance.
• Unattended upgrades: how the instance follows GitLab releases.
• Batched background migrations: how an upgrade waits on them before it advances.
• Chart provenance verification: how a pulled chart is checked against the GitLab signature.

Cleanup is shared with Siphon and has a spec of its own: Object cleanup. So does reading a version from a ConfigMap: Version reference.

Requirements

• The reconciler runs only in a build with the bridge tag and with ENABLE_BRIDGE=true. Without either, the manager starts with no GitLabCore watch.
• Each pass renders the chart version the instance converges to next, and applies every rendered object except definitions and RBAC.
• An object deleted or edited by hand is restored on the next successful pass, at most 30 seconds after the previous one, with no change to the resource, unless the pass waits for the GitLabSecrets of the release.
• A field another manager set on an applied object is taken back, and a field the chart stops rendering is removed.
• The pre-install hooks of the chart run once per release: again when the spec changes, when the chart version changes, or when a pass failed or waited for the GitLabSecrets before they completed, and not on any other pass. For the wait, see GitLab secrets.
• A chart version missing from the charts directory is pulled from the chart repository, and renders only once its signature verifies (see Chart provenance verification). With ENABLE_DYNAMIC_CHART_PULL=false, the version fails with an error that names the bundled ones.
• No custom resource definition and no RBAC object is ever applied, hooks included.
• An object whose API the cluster does not serve fails the pass, and Available names its kind.
• The status reports Initialized once the hooks ran, and Available once every rendered workload has its replicas ready.
• status.version reports the chart version applied, and status.gitlabVersion the GitLab version that chart deploys.

Out of scope

• The deprecated v1beta1 GitLab resource, which a separate controller serves.
• Converting a GitLab into a GitLabCore.
• Validating the chart values at admission.
• Running the pre-upgrade, post-install, or pre-delete hooks.

FAQ

• Why does the reconciler not watch the objects it applies? A release is hundreds of objects of kinds the Operator does not know ahead of time. The pass polls instead. For more information, see ADR 30.
• Why are the hooks not run on every pass? Running them again deletes and recreates the shared secrets Job, and waits for its pod.
• Why is RBAC never applied? It would turn the right to write a GitLabCore into the right to grant any permission the Operator holds. For more information, see ADR 31.
• Is a pulled chart verified? Yes, against the GitLab chart signing key by default. For more information, see Chart provenance verification.
• Where does status.gitlabVersion come from? From the render, not from a catalog, because a pulled chart is in no catalog. Siphon reads it to pin its table definitions.