I believe `specialized-workers` is a better name than `room-workers`,
because when enabled, 4 different types of specialized workers are
created:
- Room workers
- Sync workers
- Client readers
- Federation readers
Only one of these is called room-workers.
In the future, more specialized workers may be added, making the
`room-workers` preset name an even poorer choice.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3100
Until now, the validation check would only get tripped up
if generic workers are used, combined with at least one EACH
other type of specialized workers.
This means that someone doing this:
```
matrix_synapse_workers_preset: one-of-each
matrix_synapse_workers_client_reader_workers_count: 5
```
.. would not have triggered this safety check.
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3100
After some checking, it seems like there's `/_synapse/client/oidc`,
but no such thing as `/_synapse/oidc`.
I'm not sure why we've been reverse-proxying these paths for so long
(even in as far back as the `matrix-nginx-proxy` days), but it's time we
put a stop to it.
The OIDC docs have been simplified. There's no need to ask people to
expose the useless `/_synapse/oidc` endpoint. OIDC requires
`/_synapse/client/oidc` and `/_synapse/client` is exposed by default
already.
Issues and Pull Requests were not migrated to the new
organization/repository, so `matrix-org/synapse/pull` and
`matrix-org/synapse/issues` references were kept as-is.
`matrix-org/synapse-s3-storage-provider` references were also kept,
as that module still continues living under the `matrix-org` organization.
This patch mainly aims to change documentation-related things, not actual
usage in full yet. For polish that, another more comprehensive patch is coming later.
This moves the comments from being just in Jinja,
to actually ending up in the generated `labels` file,
which makes inspection of the final result easier.
Also, some new lines were added here and there to make labels
more legible.
The generated file may still include weird new-lines due to
various `if` statements yielding content or not, but that's not so ugly
anymore - now that we have proper start/end sections that are visible in
the final `labels` file.
We'd be adding integration with an internal Traefik entrypoint
(`matrix_playbook_internal_matrix_client_api_traefik_entrypoint`),
so renaming helps disambiguate things.
There's no need for deperecation tasks, because the old names
have only been part of this `bye-bye-nginx-proxy` branch and not used by
anyone publicly.
This is an attempt at optimizing service startup.
The effect is most pronounced when many services are restarted one by one.
The systemd service manager role sometimes does this - for example when `just install-service synapse` runs.
In such cases, a 5-second delay for each Synapse worker service
(or other bridge/bot service that waits on the homeserver) quickly adds up to a lot.
When services are all stopped fully and then started, the effect is not so pronounced, because
`matrix-synapse.service` starts first and pulls all worker services (defined as `Wants=` for it).
Later on, when the systemd service manager role "starts" these worker services, they're started already.
Even if they had a 5-second wait each, it would have happened in parallel.
This also updates validation tasks and documentation, pointing to
variables in the matrix-synapse role which don't currently exist yet
(e.g. `matrix_synapse_container_labels_client_synapse_admin_api_enabled`).
These variables will be added soon, as Traefik labels are added to the
`matrix-synapse` role. At that point, the `matrix-synapse-reverse-proxy-companion` role
will be updated to also use them.
Many of these do depend on the Synapse master process (`matrix-synapse.service`),
so it makes sense to do it.
Furthermore, we're doing it so that one can stop the `matrix-synapse.service`
service and have systemd cascade this into stopping all the workers as well.
This is useful for easily stopping all of Synapse, so that Postgres
upgrades (`--tags=upgrade-postgres`) can happen cleanly.
Postgres upgrades currently stop `devture_postgres_systemd_services_to_stop_for_maintenance_list` which
includes Synapse, but stopping just the master process and leaving workers running is not safe enough and sometimes leads to errors like:
> ERROR: insert or update on table "event_forward_extremities" violates foreign key constraint "event_forward_extremities_event_id"
With this dependency in place, stopping `matrix-synapse.service` will stop all Synapse processes.
`spam_checker` has been deprecated for quite a while.
While it still probably works and while newer versions of
mjolnir-antispam still use it, we should switch to the new API.
