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.
`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.
This was mostly affecting the stream writer (events) worker, which was
being reported as unhealthy. It wasn't causing any issues, but it just
looked odd and was confusing people.
As an alternative to hitting the regular `/health` healthcheck route (on
the "client" API which this stream writer does not expose),
we may have went for hitting some "replication" API endpoint instead.
This is more complicated and likely unnecessary.
Without these:
- `--tags=install-synapse` and `--tags=install-all` would be incomplete
and will not contain Synapse worker configuration
- `--tags=install-synapse-reverse-proxy-companion` and
`--tags=setup-synapse-reverse-proxy-companion` would not contain
Synapse worker configuration
- forego removing Docker images - it's not effective anyway, because it
only removes the last version.. which is a drop in the bucket, usually
- do not reload systemd - it's none of our business. `--tags=start`,
etc., handle this
- combine all uninstall tasks under a single block, which only runs if
we detect traces (a leftover systemd .service file) of the component.
If no such .service is detected, we skip them all. This may lead to
incorect cleanup in rare cases, but is good enough for the most part.
