fnux-playground: expand matrix configuration

apps/fnux-playground/matrix.fnux-playground.yaml

@@ -1,26 +1,36 @@
-# TODO: set redis & PGSQL password, investigate workers.
+# Note: as of writing we can't template the variables of this file, although
+# I'm pretty sure upstream would accept a patch for this.
 
-# Synapse configuration.
+# Shared variables.
+clusterName: "c2.k8s.ooo"
+
+# The Matrix domain name, this is what will be used for the domain part in
+# your MXIDs.
+serverName: "matrix.fnux-playground.svc.c2.k8s.ooo"
+
+# The public Matrix server name, this will be used for any public URLs
+# in config as well as for client API links in the ingress.
+publicServerName: "matrix.fnux-playground.svc.c2.k8s.ooo"
+
+# Generic configuration that apply to mixed components.
 config:
+  # Log level for Synapse and all modules.
   logLevel: INFO
 
-# Synapse persistence.
+# Configuration to apply to the main Synapse pod.
-persistence:
-  enabled: true
-  storageClass: "rook-cephfs"
-  accessMode: ReadWriteMany
-  size: 10Gi
-
-# PGSQL persistence.
-postgresql:
-  enabled: true
-  persistence:
-    storageClass: "rook-cephfs"
-    size: 16Gi
-
-# First/initial startup is slow! The synapse pod get killed before the database
-# is fully initialied if we don't explicitely wait.
 synapse:
+  ## Only really applicable when the deployment has an RWO PV attached (e.g. when media repository
+  ## is enabled for the main Synapse pod)
+  ## Since replicas = 1, an update can get "stuck", as the previous pod remains attached to the
+  ## PV, and the "incoming" pod can never start. Changing the strategy to "Recreate" will
+  ## terminate the single previous pod, so that the new, incoming pod can attach to the PV
+  ##
+  strategy:
+    type: RollingUpdate
+  # First/initial startup is slow! The synapse pod get killed before the
+  # database is fully initialied if we don't explicitely wait.
+  # XXX: we should probably use a startupProbe, but this need to be patched
+  # upstream.
   livenessProbe:
     httpGet:
       path: /health
@@ -32,6 +42,22 @@ synapse:
       port: http
     initialDelaySeconds: 180
 
+# Configuration for handling Synapse workers, which are useful for handling
+# high-load deployments.
+#
+# More information is available at;
+# https://github.com/matrix-org/synapse/blob/master/docs/workers.md
+#
+# workers: ...
+
+# Persistence configuration for the media repository function.  This PVC will
+# be mounted in either Synapse or a media_repo worker.
+persistence:
+  enabled: true
+  storageClass: "rook-cephfs"
+  accessMode: ReadWriteMany
+  size: 10Gi
+
 # Serve /.well-known URIs, making federation possible without adding
 # SRV-records to DNS.
 wellknown:
@@ -44,10 +70,33 @@ wellknown:
   # Data served on .well-known/matrix/server.
   # See https://matrix.org/docs/spec/server_server/latest#get-well-known-matrix-server
   server:
-    m.server: "matrix.fnux-playground.svc.c1.k8s.oo:443"
+    m.server: "matrix.fnux-playground.svc.c2.k8s.ooo"
 
   # Data served on .well-known/matrix/client.
   # See https://matrix.org/docs/spec/client_server/latest#get-well-known-matrix-client
   client:
     m.homeserver:
-      base_url: "https://matrix.ungleich.ch"
+      base_url: "https://matrix.fnux-playground.svc.c2.k8s.ooo"
+
+# PGSQL database server configuration.
+postgresql:
+  enabled: true
+  postgresqlPassword: "secret"
+  postgresqlUsername: synapse
+  postgresqlDatabase: synapse
+  persistence:
+    storageClass: "rook-cephfs"
+    size: 16Gi
+
+## Redis server for use with workers/sharding.
+redis:
+  enabled: true
+  usePassword: true
+  password: "secret"
+
+# The K8s ingress configuration, this will be quite heavily used in order to
+# set up all routing necessary for use with a sharded Synapse instance. If
+# you're not using a Ingress compatible K8s ingress, you will need to set up
+# your own routing instead.
+ingress:
+  enabled: true