GitLab instance form

Status: Implemented Issue: none Parent: none

Goal

An administrator creates and edits a GitLab instance, and its add-ons, in the Bridge UI without writing YAML, and can leave the form half-filled while looking at another section.

Requirements

  • The form writes one GitLabCore, in sections: Basics, Dependencies, Networking, Core Components, Add-ons, and Overrides. Core Components follows Components in the form.
  • Moving between sections validates nothing.
  • A section with unsaved changes shows a dot, and a section that fails validation a red mark.
  • Create and Save validate the sections in order, and open the first one that fails.
  • The PostgreSQL, Valkey, object storage, ClickHouse, and license groups are each all-or-nothing. An incomplete group is reported before any request is sent.
  • The license group shows for Enterprise Edition only. Community Edition sends no license.
  • A new instance needs a namespace, which a dropdown in Basics chooses. Nothing is chosen at first.
  • The dropdown searches the namespaces the Bridge API lists as the user types, and offers to create the typed name when no listed namespace has it.
  • The dropdown never offers a hidden name, and says why when one is typed. It offers no typed name until the list, which carries the rules for hidden names, has loaded.
  • When the caller may not list namespaces, the dropdown offers to use or to create the typed name.
  • A namespace chosen for creation is created on Create, before the instance. A namespace that exists by then is used.
  • An existing resource is edited in its own namespace, and neither its namespace nor its name can change.
  • The chart version has no default and no fixed list of choices.
  • Manual networking leaves spec.networking unset.
  • The Secret Manager, Container Registry, and Toolbox add-ons write spec.components, and follow GitLab components. The Orbit add-on follows Orbit add-on. Add-ons that are not built yet show as disabled.
  • Enabling Siphon writes a Siphon resource of its own, after the instance is saved.
  • When the Siphon fails to save, the instance stays saved, and the form stays open on the add-on. Saving again updates the instance and retries the Siphon, without creating the instance again.
  • Clearing Enable Siphon on an existing Siphon shows a warning before the save. It names the replication slot the deletion leaves, and says that until the slot is dropped, pg_wal grows until PostgreSQL stops accepting writes, vacuum cannot clean the system catalogs, and a failover slot has copies on the standbys. It gives the statements that drop the slot and the publication, and names the NATS stream.
  • Saving then deletes the Siphon only once its name is typed. Declining, or typing another name, keeps the Siphon. The ClickHouse group stays either way.
  • Saving with Siphon on fails validation on the Siphon section while the instance has no ClickHouse, as GitLab ClickHouse integration defines it. That covers enabling Siphon, clearing the ClickHouse group, and an instance whose Siphon predates it.
  • Switching Siphon on fills an empty sink host from the host of the ClickHouse URL, and an empty sink database from the ClickHouse database. It fills nothing else, and overwrites no value.
  • A caller who cannot read Siphon resources can still save the instance. The add-on shows as Unknown and locked, and an existing Siphon is left untouched.
  • While a Siphon exists, the panel reports its PostgreSQL publication, replication slot, and NATS stream. While a condition is not True, it also gives the reason and message of the first one.

Out of scope

  • Deleting a namespace.
  • Requesting an OpenShift project for a caller who may not create namespaces.
  • A schema for the chart values in the Overrides section.
  • Editing the chart values of a Siphon in the form.

FAQ

  • Why is Siphon saved after the instance? The Siphon references the instance, not the other way around.
  • Why does deleting a Siphon take its name typed out? Deleting it stops the pipeline and leaves the publication, the replication slot, and the NATS stream behind. Nothing reads the slot any more, so it puts the whole database at risk, not only Siphon: PostgreSQL stops accepting writes once pg_wal fills. A single confirmation is too little for a step with that consequence. The Operator cannot drop the slot itself, because it did not create it. A deprovisioning runbook or command from Siphon is requested in Siphon issue 350.
  • Why does the form fill only the sink host and database? They are the same server and database. The port, the user, the password, and TLS differ between the two connections.
  • Why does the form keep the chart values of a Siphon it cannot edit? The save replaces the whole resource, so values the form did not load would otherwise be dropped.
  • When is a new namespace created? When the form is submitted, so an abandoned form leaves none behind.
  • What happens when the namespace is created and the instance is not? The namespace stays. Saving again uses it.
  • What if a name typed to use names no namespace? Creating the instance fails, and the error names the namespace.
  • What if a name typed to create is a namespace being deleted? Create refuses it and says so, before the instance.
  • Why is nothing chosen at first? So an instance lands where the user decided, not in a default.
  • Why is default not hidden? It is not a system namespace. The requester kept it.
  • Does an instance start in a new namespace? With a chart that renders a GitLabSecrets, 10.5 and later, yes. An earlier chart runs the shared secrets Job, which needs the ServiceAccount of the Operator in that namespace. The Operator must also run in cluster mode, because in namespaced mode it watches only its own namespace.