Siphon and Orbit deprovisioning

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

Goal

An administrator removes Orbit, Siphon, or both from an instance, with kubectl or in the Bridge UI, and knows what goes, what stays, and what GitLab keeps using. Removing either one never changes how GitLab connects to ClickHouse. For the connection, see GitLab ClickHouse integration. For the rendered objects, see Object cleanup.

Requirements

This spec lists what deleting a Siphon or an Orbit leaves. For the form and the Bridge API, see GitLab instance form and Orbit add-on. For what the Orbit reconciler removes, see Orbit reconciler.

  • Deleting a Siphon removes the objects its chart rendered and the ConfigMap of table definitions the Operator published.
  • It leaves the replication slot, the publication, the NATS stream, and the tables and rows in ClickHouse in place. It emits a ReplicationSlotRetained warning event that names the slot.
  • Deleting a Siphon changes nothing on its GitLabCore. spec.clickhouse and the ClickHouse chart values stay, and the instance renders the same release as before.
  • A Siphon deleted with kubectl under an Orbit makes the Orbit wait with reason SiphonNotFound. What the Orbit applied keeps running.
  • Deleting an Orbit changes neither its Siphon nor the ClickHouse connection of the instance. It leaves the ClickHouse users and the Secrets it references in place.
  • An Orbit deleted with kubectl leaves spec.orbitRef in place. The instance renders without the Orbit settings and reports OrbitConnected=False with reason OrbitNotFound. An Orbit created again under that name connects GitLab again.

Out of scope

  • Dropping the replication slot, the publication, the NATS streams, the graph database, or any ClickHouse table. The Operator did not create them.
  • Deleting the GitLabCore. Its Siphon and Orbit stay, and wait for an instance of that name.
  • Refusing at admission a kubectl deletion of a Siphon that an Orbit uses.
  • Turning off the ClickHouse integration of GitLab, which an edit of the instance does.

FAQ

  • Why does deleting a Siphon keep the ClickHouse connection of GitLab? Other GitLab features that use ClickHouse can stay in use without Siphon, and removing the connection would break them. Siphon fills only some of the tables there, and the GitLab migrations own all of them.
  • Why does the Bridge API remove spec.orbitRef, but a kubectl deletion does not? The API acts for the administrator, who turned Orbit off. No reconciler writes the spec of another resource, so after a kubectl deletion the reference stays, and the condition says why GitLab is not connected.
  • What has to be cleaned up by hand? The replication slot first. PostgreSQL keeps write-ahead log for an inactive slot, and a forgotten one fills the volume of the source server. For the statements, see Siphon.