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
These `init.yml` (now `inject_into_nginx_proxy.yml`) tasks do not need
to `always` run. They only need to run for `setup-all` and
`setup-nginx-proxy`. Unless we're dealing with these 2 tags, we can
spare ourselves a lot of work.
This patch also moves the `when` statement from `init.yml` into
`main.yml` in an effort to further optimize things by potentially
avoiding the extra file include.
As stream writer workers are also powered by the `generic_worker`
Synapse app, this necessitated that we provide means for distinguishing
between them and regular `generic_workers`.
I've also taken the time to optimize nginx configuration generation
(more Jinja2 macro usage, less duplication).
Worker names have also changed.
Workers are now named sequentially like this:
- `matrix-synapse-worker-0-generic`
- `matrix-synapse-worker-1-stream-writer-typing`
- `matrix-synapse-worker-2-pusher`
instead of `matrix-synapse-worker_generic_worker-18111` (indexed with a
port number).
People who modify `matrix_synapse_workers_enabled_list` directly will
need to adjust their configuration.
For now, we disable the new `com.devture.shared_secret_auth` login type
by default, because it causes problems with Element:
https://github.com/vector-im/element-web/issues/19605
This also becomes the first module to use the new Synapse module system
that got introduced in Synapse v1.46.0.
Despite these upgrades, things should remain functionally identical
as far as bridges, matrix-corporal or other consumers are concerned.
This leads to much easier management and potential safety
features (validation). In the future, we could try to avoid port
conflicts as well, but it didn't seem worth the effort to do it now.
Our port ranges seem large enough.
This can also pave the way for a "presets" feature
(similar to `matrix_nginx_proxy_ssl_presets`) which makes it even easier
for people to configure worker counts.
This switches the `docker exec` method of spawning
Synapse workers inside the `matrix-synapse` container with
dedicated containers for each worker.
We also have dedicated systemd services for each worker,
so this are now:
- more consistent with everything else (we don't use systemd
instantiated services anywhere)
- we don't need the "parse systemd instance name into worker name +
port" part
- we don't need to keep track of PIDs manually
- we don't need jq (less depenendencies)
- workers dying would be restarted by systemd correctly, like any other
service
- `docker ps` shows each worker separately and we can observe resource
usage
As suggested in #63 (Github issue), splitting the
playbook's logic into multiple roles will be beneficial for
maintainability.
This patch realizes this split. Still, some components
affect others, so the roles are not really independent of one
another. For example:
- disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse
and riot-web to reconfigure themselves with other (public)
Identity servers.
- enabling matrix-corporal (`matrix_corporal_enabled: true`) affects
how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to
put matrix-corporal's gateway server in front of Synapse
We may be able to move away from such dependencies in the future,
at the expense of a more complicated manual configuration, but
it's probably not worth sacrificing the convenience we have now.
As part of this work, the way we do "start components" has been
redone now to use a loop, as suggested in #65 (Github issue).
This should make restarting faster and more reliable.
Slavi Pantaleev
Marko Weltzer
Michael Collins
Aaron Raimist
Horvath Gergely
Dan Arnfield