Version reference

Status: Implemented Issue: https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/work_items/2255 Parent: none

Goal

A platform that ships a tested set of components sets the exact chart version of a GitLabCore or a Siphon in an object it owns, while the owner of the resource keeps owning its spec.

Requirements

  • A Siphon selects its chart version in spec.version, shaped like the one of a GitLabCore, with the Static type only. spec.chart carries the values only.
  • A Static version of either resource takes its version from version, or from versionRef, which names a kind, a name, and a key. The only kind is ConfigMap, read from the namespace of the resource.
  • A version with both version and versionRef, or with neither, is rejected. So is a GitLabCore versionRef on a type other than Static, and a Siphon type other than Static.
  • The referenced version behaves exactly as the literal one: a GitLabCore runs it, upgrades when it changes, and refuses a downgrade, and a Siphon renders that chart version.
  • A change to the referenced ConfigMap, including its creation, reconciles every resource in the namespace that references it, with no change to the resource.
  • A missing ConfigMap or key, or a value that is not a semantic version, fails the pass of a Siphon, and of a GitLabCore with no target yet, with Initialized=False and reason VersionUnresolved. A GitLabCore with a target keeps it, an upgrade in progress included, and reports Upgradeable=False with the same reason. Neither deletes what it already applied.
  • Replacing versionRef with a literal version, or the reverse, is an ordinary change of the version, so a GitLabCore that switches back to a reference that lags refuses it as a downgrade.
  • The bridge API reads and writes versionRef on both resources, and its web UI keeps a reference it loaded until a version is typed in its place.

Out of scope

  • A Secret as the source of a version.
  • A reference to an object in another namespace.
  • A reference for the types that follow the chart repository, such as a minor or a major.
  • Siphon types other than Static, and a downgrade refusal for Siphon.
  • Editing a reference in the web UI.

FAQ

  • Why only ConfigMap? A version is not secret, and reading Secrets widens what the Operator watches. The kind field leaves room to add Secret without breaking the API.
  • Why only the Static type? The other types already move without a change to the spec. A platform that wants to pin a version uses Static.
  • Why does a Siphon have spec.version with a single type? It follows GitLabCore, so both resources select a version the same way. A Siphon chart is never pulled, so there is no repository to follow, and Static is the only type that makes sense today. The union leaves room for more.
  • Can the owner take control back? Yes. Replacing versionRef with version picks up any version at once, for example a fix ahead of the platform.
  • Does the Operator write the referenced version into the spec? No, for the reason Unattended upgrades gives. A GitLabCore reports it in status.targetVersion, and a Siphon in status.version once applied.