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, Add-ons, and Overrides.
  • 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, 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 add-on writes spec.openbao. 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 deletes the Siphon after a confirmation. Declining keeps it.
  • 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 the form warn before deleting a Siphon? Deleting it stops the pipeline and leaves the publication, the replication slot, and the NATS stream behind. A retained slot pins write-ahead log on the source server until its volume fills.
  • 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.