add details on the Puppet configuration

tsa/howto/gitlab.md

@@ -184,17 +184,31 @@ TBD
 
 The current GitLab server was setup in the [[ganeti]] cluster in a
 regular virtual machine. It was configured with [[puppet]] with the
-`roles::gitlab`.
+`roles::gitlab`. That, in turn, relies on a series of `profile`
+elements which configure:
+
+ * `profile::gitlab::web`: nginx vhost and TLS cert, depends on
+   `profile::nginx` built for the [[cache]] service and relying on the
+   [puppet/nginx](https://forge.puppet.com/puppet/nginx) module from the Forge
+ * `profile::gitlab::mail`: dovecot and postfix configuration, for
+   email replies
+ * `profile::gitlab::database`: postgresql configuration, possibly not
+   used by the Omnibus package, see [issue 20](https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/20)
+ * `profile::gitlab::app`: the core of the configuration of gitlab
+   itself, uses the [puppet/gitlab](https://forge.puppet.com/puppet/gitlab) module from the Forge, with
+   Prometheus, Grafana, and Nginx support disabled, but Redis,
+   PostgreSQL, and Prometheus exporters enabled
 
 This installs the [GitLab Omnibus](https://docs.gitlab.com/omnibus/) distribution which duplicates a
 lot of resources we would otherwise manage elsewhere in Puppet,
 including (but possibly not limited to):
 
- * [[prometheus]]
+ * [[prometheus]] exorters
  * [[postgresql]]
+ * redis
 
 This therefore leads to a "particular" situation regarding monitoring
-and PostgreSQL backups, in particular.
+and PostgreSQL backups, in particular. See [issue 20](https://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/20) for details.
 
 ## SLA
 <!-- this describes an acceptable level of service for this service -->