postgres: its server container is not named after the seat

The module's server container was called mesh-store and its data directory /var/lib/mesh-store — the seat's name reused for the module's own resources, a leftover from the first migration. On a machine whose postgres holds no seat (ace, as a database provider only) that produced a container called mesh-store holding nothing of the kind. The container is now named postgres. The data directory keeps its path: a path change recreates a running container on an empty directory (hq 126), and novox's store lives there. Rolling this out recreates novox's store container once (a restart on its bind mount, no data moves). The two catalogue-test failures on this branch (resolver_manifests_test) fail identically on main today.
Merge pull request 'dnsmasq: answer a container's query, which arrives on the runtime's bridge' (#176 ) from fix/110-the-resolver-answers-a-container into main
2026-09-30 14:56:31 +02:00 · 2026-09-30 12:31:30 +00:00 · 2026-09-30 14:31:26 +02:00 · 2026-09-30 12:22:10 +00:00 · 2026-09-30 14:22:03 +02:00 · 2026-09-30 12:06:25 +00:00
3 changed files with 15 additions and 116 deletions
@@ -1,110 +0,0 @@
-{
-  "module": "matrix",
-  "version": "1",
-  "capabilities": [
-    "container-runtime"
-  ],
-  "listens": [
-    {
-      "name": "client",
-      "port": 6167,
-      "protocol": "tcp",
-      "from": "mesh",
-      "why": "Conduit's client-server and federation APIs over plain HTTP. Both arrive through the route on 443: Conduit answers /.well-known/matrix/server with <its name>:443, so other homeservers federate through the proxy and nothing needs the traditional 8448"
-    },
-    {
-      "name": "web",
-      "port": 80,
-      "protocol": "tcp",
-      "from": "mesh",
-      "why": "Element Web, the static browser client, served by the image's nginx; reached through its route"
-    }
-  ],
-  "requires": [
-    "route"
-  ],
-  "contributes": {
-    "route": {
-      "homeserver": {
-        "label": "matrix",
-        "endpoint": "client"
-      },
-      "element": {
-        "label": "element",
-        "endpoint": "web"
-      }
-    }
-  },
-  "binds": {
-    "route": "${dir:state}/route.json"
-  },
-  "resources": [
-    {
-      "id": "state",
-      "type": "directory",
-      "mode": "0700",
-      "place": "."
-    },
-    {
-      "id": "db",
-      "type": "directory",
-      "mode": "0700"
-    },
-    {
-      "id": "conduit-conf",
-      "type": "file",
-      "path": "${dir:state}/conduit.toml",
-      "mode": "0644",
-      "content": "# Written by the mesh (modules/matrix). Conduit reads this file (CONDUIT_CONFIG); nothing comes\n# from the environment. server_name is the homeserver's permanent identity: every user id, room id\n# and signature in the database carries it, so it is the name this module is served under\n# (${bound:route:name-homeserver}) and never changes once a database exists.\n[global]\nserver_name = \"${bound:route:name-homeserver}\"\ndatabase_backend = \"rocksdb\"\ndatabase_path = \"/var/lib/matrix-conduit/\"\naddress = \"0.0.0.0\"\nport = 6167\nmax_request_size = 20000000\nallow_registration = false\nallow_federation = true\nallow_check_for_updates = true\ntrusted_servers = [\"matrix.org\"]\n"
-    },
-    {
-      "id": "element-conf",
-      "type": "file",
-      "path": "${dir:state}/element.json",
-      "mode": "0644",
-      "merge": "json",
-      "content": "{\n  \"default_server_name\": \"${bound:route:name-homeserver}\",\n  \"default_server_config\": {\n    \"m.homeserver\": {\n      \"base_url\": \"https://${bound:route:name-homeserver}\"\n    },\n    \"m.identity_server\": {\n      \"base_url\": \"https://vector.im\"\n    }\n  },\n  \"brand\": \"Element\",\n  \"integrations_ui_url\": \"https://scalar.vector.im/\",\n  \"integrations_rest_url\": \"https://scalar.vector.im/api\",\n  \"integrations_widgets_urls\": [\n    \"https://scalar.vector.im/_matrix/integrations/v1\",\n    \"https://scalar.vector.im/api\",\n    \"https://scalar-staging.vector.im/_matrix/integrations/v1\",\n    \"https://scalar-staging.vector.im/api\",\n    \"https://scalar-staging.riot.im/scalar/api\"\n  ],\n  \"bug_report_endpoint_url\": \"https://element.io/bugreports/submit\",\n  \"uisi_autorageshake_app\": \"element-auto-uisi\",\n  \"show_labs_settings\": true,\n  \"room_directory\": {\n    \"servers\": [\n      \"${bound:route:name-homeserver}\",\n      \"matrix.org\",\n      \"gitter.im\",\n      \"libera.chat\"\n    ]\n  },\n  \"enable_presence_by_hs_url\": {\n    \"https://matrix.org\": false,\n    \"https://matrix-client.matrix.org\": false\n  },\n  \"terms_and_conditions_links\": [\n    {\n      \"url\": \"https://element.io/privacy\",\n      \"text\": \"Privacy Policy\"\n    },\n    {\n      \"url\": \"https://element.io/cookie-policy\",\n      \"text\": \"Cookie Policy\"\n    }\n  ],\n  \"features\": {\n    \"feature_video_rooms\": true,\n    \"feature_rust_crypto\": true\n  },\n  \"element_call\": {\n    \"url\": \"https://call.element.dev\"\n  }\n}\n"
-    },
-    {
-      "id": "net",
-      "type": "network",
-      "name": "matrix"
-    },
-    {
-      "id": "homeserver",
-      "type": "container",
-      "name": "matrix",
-      "image": "matrixconduit/matrix-conduit@sha256:b0d24248e94f944ca49f90f10c429e3d65f4472bdde25661ecea9840134fb133",
-      "network": "matrix",
-      "env": {
-        "CONDUIT_CONFIG": "/etc/conduit/conduit.toml"
-      },
-      "ports": [
-        "6167"
-      ],
-      "volumes": [
-        "${dir:db}:/var/lib/matrix-conduit",
-        "${dir:state}/conduit.toml:/etc/conduit/conduit.toml:ro"
-      ],
-      "restart-on": [
-        "conduit-conf"
-      ]
-    },
-    {
-      "id": "element",
-      "type": "container",
-      "name": "element-web",
-      "image": "vectorim/element-web@sha256:a8f415462ab8d2600a592ba1b92bea51efe5a4d10eb738aab9bed769f7099613",
-      "network": "matrix",
-      "ports": [
-        "80"
-      ],
-      "volumes": [
-        "${dir:state}/element.json:/app/config.json:ro"
-      ],
-      "restart-on": [
-        "element-conf"
-      ]
-    }
-  ]
-}
@@ -80,7 +80,7 @@
    {
      "id": "server",
      "type": "container",
-      "name": "mesh-store",
+      "name": "postgres",
      "image": "pgvector/pgvector@sha256:cf134a767f474095eeba57e0117be8e568e011a63f33fbf252f14c9b760f8e6f",
      "env": {
        "POSTGRES_PASSWORD_FILE": "/run/secrets/superuser",
@@ -105,7 +105,7 @@
        "/var/lib/postgres/superuser.secret:/run/secrets/superuser:ro"
      ],
      "env": {
-        "MESH_PROVISION_POSTGRES": "postgres://postgres@127.0.0.1:5432/postgres?sslmode=disable",
+        "MESH_PROVISION_POSTGRES": "postgres://postgres@127.0.0.1:${port:5432}/postgres?sslmode=disable",
        "MESH_PROVISION_POSTGRES_PORT": "${seat:mesh-store:5432}",
        "MESH_PROVISION_PASSWORD_FILE": "/run/secrets/superuser",
        "MESH_BROKER_FILE": "/run/secrets/broker",
Author	SHA1	Message	Date
jschoubben	76443ec06d	postgres: its server container is not named after the seat The module's server container was called mesh-store and its data directory /var/lib/mesh-store — the seat's name reused for the module's own resources, a leftover from the first migration. On a machine whose postgres holds no seat (ace, as a database provider only) that produced a container called mesh-store holding nothing of the kind. The container is now named postgres. The data directory keeps its path: a path change recreates a running container on an empty directory (hq 126), and novox's store lives there. Rolling this out recreates novox's store container once (a restart on its bind mount, no data moves). The two catalogue-test failures on this branch (resolver_manifests_test) fail identically on main today.	2026-09-30 14:56:31 +02:00
jschoubben	7ab522ba31	Merge pull request 'dnsmasq: answer a container's query, which arrives on the runtime's bridge' (#176 ) from fix/110-the-resolver-answers-a-container into main	2026-09-30 12:31:30 +00:00
jschoubben	204bfbbaf9	dnsmasq: answer a container's query, which arrives on the runtime's bridge dnsmasq admits a query by the interface it arrives on when told interface=, and by the address it is sent to when told listen-address=. A container's query is sent to the machine's private address but arrives on docker0, so interface=mesh0 dropped it silently on every machine (novox/hq issue 110). Name the address, not the interface.	2026-09-30 14:31:26 +02:00
jschoubben	e0c09f46b6	Merge pull request 'dnsmasq: the runtime is reloaded when its dns file changes, and may then be restarted safely' (#175 ) from fix/110-the-runtime-reads-its-dns into main	2026-09-30 12:22:10 +00:00
jschoubben	e0faf012be	dnsmasq: the runtime is reloaded when its dns file changes, and may then be restarted safely novox/hq 04-ISSUES/110. The module writes the runtime's `dns` key and deliberately ordered no restart, because a restart stops every container. It also ordered no reload, and the key holds only for containers created after the runtime next starts. On two of four machines the runtime predated the file — one since August — so every container there was handed a public resolver and no mesh name resolved, while everything read as fine. The third machine works only because its runtime happened to restart later. The file now also sets live-restore, which the runtime reads on a reload, and the module declares the runtime reloaded when the file changes (ADR 0102: reload, don't restart). A reload still does not make `dns` take effect; what it does is make the one restart that key needs keep every container running. That restart stays the operator's, once per machine, and is harmless from the second time on. The mesh restarts nothing here. Undeclared, the runtime's unit goes back to the state it was found in (ADR 0118).	2026-09-30 14:22:03 +02:00
mesh-admin	1b19c79d63	Merge pull request 'postgres: the provisioner dials the port the mesh gave the store' (#174 ) from fix/postgres-provisioner-dials-the-port-it-was-given into main	2026-09-30 12:06:25 +00:00
jschoubben	4ec2ae1f7f	postgres: the provisioner dials the port the mesh gave the store MESH_PROVISION_POSTGRES named 127.0.0.1:5432 literally; the seat twin (${seat:mesh-store:5432}) corrected it only on the machine holding the mesh-store seat. On any other machine — ace, where the module provides postgres-database without the seat — the twin is empty and the sidecar would have dialled whatever else holds 5432 (HAL's postgres). ${port:5432} is the machine port on every node; on novox the twin still says the same 6852, so nothing moves there.	2026-09-30 14:01:53 +02:00