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:

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.
  • 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 before they completed, and not on any other pass.
  • 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.