pub-solar/matrix-docker-ansible-deploy
5
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity
2717 commits 2 branches 0 tags 16 MiB
Commit graph

351 commits

Author SHA1 Message Date
Michael-GMH 85777e8f96 merge with upstream 2021-05-25 21:08:00 +08:00
Michael-GMH 4e6f6e179b GMH 0.4.6 update 2021-05-10 18:50:10 +08:00
Slavi Pantaleev 61220ea487 Upgrade Synapse (1.33.0 -> 1.33.1) 2021-05-06 20:47:09 +03:00
Slavi Pantaleev d4d1e2e922 Upgrade Synapse (1.32.2 -> 1.33.0) 2021-05-05 19:18:53 +03:00
Slavi Pantaleev f6b371164c Remove useless variable 2021-04-23 07:07:18 +03:00
Slavi Pantaleev e3fa3e12bc Upgrade Synapse (1.31 -> 1.32.2) 2021-04-22 14:22:07 +03:00
Slavi Pantaleev 378fabf177 Revert "Upgrade Synapse (1.31 -> 1.32.1)" 
This reverts commit 1fb54a37cb.

Seems like it's been pulled or something. It used to exist, but not
anymore. Not sure what's going on.

Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1017

Related to
https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1010
 2021-04-21 23:36:58 +03:00
Slavi Pantaleev 1fb54a37cb Upgrade Synapse (1.31 -> 1.32.1) 
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1010
 2021-04-21 18:47:15 +03:00
Slavi Pantaleev ca786cc343 Revert "Upgrade Synapse (1.31 -> 1.32)" 
This reverts commit f825c7c263.

Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/1010
 2021-04-20 23:40:55 +03:00
Slavi Pantaleev f825c7c263 Upgrade Synapse (1.31 -> 1.32) 2021-04-20 17:47:34 +03:00
Ahmad Haghighi e335f3fc77 rename matrix_global_registry to matrix_container_global_registry_prefix related to #990 
Signed-off-by: Ahmad Haghighi <haghighi@fedoraproject.org>
 2021-04-12 17:23:55 +04:30
Ahmad Haghighi f52a8b6484 use custom docker registry 2021-04-12 17:23:55 +04:30
Slavi Pantaleev 4830b7d830 Upgrade Synapse for ARM64 (1.30.1 -> 1.31.0) 2021-04-06 17:22:25 +03:00
Slavi Pantaleev 3f426de599 Upgrade Synapse (1.30.1 -> 1.31.0) 2021-04-06 16:00:10 +03:00
Slavi Pantaleev f183add44d
Merge pull request #977 from aaronraimist/simple-antispam 
Upgrade synapse-simple-antispam (0.0.1 -> 0.0.3)
 2021-04-03 08:45:14 +03:00
Aaron Raimist c43bd412dd
Upgrade synapse-simple-antispam (0.0.1 -> 0.0.3) 2021-04-02 18:08:08 -05:00
Slavi Pantaleev 49868db3de Upgrade Synapse for ARM64 (1.30.0 -> 1.30.1) 2021-03-26 16:48:15 +02:00
Slavi Pantaleev 94487dc6a7 Upgrade Synapse for amd64 (1.30.0 -> 1.30.1) 2021-03-26 15:37:11 +02:00
Slavi Pantaleev d09609daa8 Fix Jinja2 syntax error 
Fixes a regression introduced in ffe649a240
 2021-03-22 17:13:10 +02:00
Slavi Pantaleev 6a3433fbad Update Synapse for ARM64 (1.29.0 -> 1.30.0) 
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/958
 2021-03-22 16:43:23 +02:00
Slavi Pantaleev ffe649a240 Update homeserver.yaml to keep up with Synapse v1.30.0 
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/958
 2021-03-22 16:43:10 +02:00
rakshazi 74106f2a80
Updated synapse 1.29.0 -> 1.30.0 2021-03-22 14:03:42 +00:00
Slavi Pantaleev f99dcd611f Pass proper UID/GID to Synapse 
Fixes a regression caused by a5ee39266c.

If the user id and group id were different than 991:991
(which used to be a hardcoded default for us long ago),
there was a mismatch between what Synapse was trying to use (991:991)
and what it was actually started with (in `--user=..`). It was then
trying to change ownership, which was failing.

This was mostly affecting newer installations which were not using the
991:991 defaults we had long ago (since a1c5a197a9).
 2021-03-19 16:44:10 +02:00
Slavi Pantaleev a5ee39266c Go through start.py when launching Synapse 
This allows us to benefit from helpful things it does for us,
like enabling jemalloc: https://github.com/matrix-org/synapse/pull/8553

We weren't going through `start.py` before, because it was causing some
conflict with our `docker run --user=...` stuff, but it doesn't seem
to be a problem anymore.

Having done this, we won't need to do things like
https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/941
anymore.
 2021-03-19 08:16:59 +02:00
Pablo Montepagano 52fe8a05b0 Adding vars to synapse for private servers. 2021-03-14 00:39:44 -03:00
Slavi Pantaleev 9b72384df7 Upgrade Synapse (1.28.0 -> 1.29.0) 2021-03-08 17:24:09 +02:00
Slavi Pantaleev ccf5915874 Upgrade Synapse for ARM64 (v1.26.0 -> v1.28.0) 2021-02-25 19:09:46 +02:00
Slavi Pantaleev ae091d7b2d Upgrade Synapse (v1.27.0 -> v1.28.0) 2021-02-25 13:40:35 +02:00
Slavi Pantaleev 2ef1d9c537 Make healthchecks work for Synapse worker containers 
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/456
 2021-02-24 07:59:14 +02:00
rakshazi 2f887f292c
added "matrix_%SERVICE%_version" variable to all roles, use it in "matrix_%SERVICE%_docker_image" var (preserving backward-compatibility) 2021-02-20 19:08:28 +02:00
Slavi Pantaleev d94d0e2ca5
Merge pull request #456 from eMPee584/synapse-workers 
Synapse workers
 2021-02-19 11:40:36 +02:00
Slavi Pantaleev 9dc87bb948 Add Synapse worker presets for easier configuration 
Adding more presets in the future would be nice.
 2021-02-19 11:38:47 +02:00
Slavi Pantaleev 2f732e4234 Update Synapse worker endpoints 2021-02-19 11:36:14 +02:00
Slavi Pantaleev 217b4a8808 Release Synapse v1.27.0 to ARM32 via self-building 
Related to: https://matrix.org/blog/2021/02/18/synapse-1-27-0-released#dropping-armv7-docker-images
 2021-02-19 09:10:16 +02:00
Slavi Pantaleev d6c4d41c2b Define instanceId property on workers 
This give us the possibility to run multiple instances of
workers that that don't expose a port.

Right now, we don't support that, but in the future we could
run multiple `federation_sender` or `pusher` workers, without
them fighting over naming (previously, they'd all be named
something like `matrix-synapse-worker-pusher-0`, because
they'd all define `port` as `0`).
 2021-02-18 18:19:51 +02:00
Slavi Pantaleev d33483b8ce Document that Synapse pusher worker instances are shardable 
Related to:
- https://github.com/matrix-org/synapse/pull/9407
- https://github.com/matrix-org/synapse/pull/7855
 2021-02-16 17:45:41 +02:00
Slavi Pantaleev daae74b074 Merge branch 'master' into synapse-workers 2021-02-16 17:31:40 +02:00
Slavi Pantaleev 521160c12f Upgrade Synapse (v1.26.0 -> v1.27.0) 2021-02-16 17:30:48 +02:00
Slavi Pantaleev 61e427d690 Do not let people enable more than 1 federation_sender worker 2021-02-15 11:37:03 +02:00
Slavi Pantaleev 85a05f38e8 Allow Synapse worker list to be generated dynamically 
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.
 2021-02-15 11:25:35 +02:00
Slavi Pantaleev 43059bb040 Fix metrics listeners for Synapse workers 
`::` leads to errors like:

> socket.gaierror: [Errno -9] Address family for hostname not supported
 2021-02-15 11:19:07 +02:00
Slavi Pantaleev 453a4ec2d8 Relocate tasks related to Synapse workers 2021-02-15 11:18:47 +02:00
Slavi Pantaleev 5cfeae806b Merge branch 'master' into synapse-workers 2021-02-14 13:00:57 +02:00
Slavi Pantaleev 7e8e95a09a Make S3-mounting path configurable 
This will make data migration easier.
 2021-02-09 22:05:07 +02:00
Béla Becker 2edc9cb83c Name the Synapse database on state compression import 
Fixes:
https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/833
 2021-01-28 17:54:02 +01:00
Slavi Pantaleev e7f3f7c431 Enable /devices endpoint for generic workers 2021-01-27 22:18:47 +02:00
Slavi Pantaleev 1cd2a218de Merge branch 'master' into synapse-workers 2021-01-27 21:41:54 +02:00
Slavi Pantaleev c6feb0b99e Upgrade Synapse (v1.25.0 -> v1.26.0) 2021-01-27 21:41:47 +02:00
Slavi Pantaleev d98a1ceadd Merge branch 'master' into synapse-workers 2021-01-27 10:27:17 +02:00
Slavi Pantaleev 512f42aa76 Do not report docker kill/rm attempts as errors 
These are just defensive cleanup tasks that we run.
In the good case, there's nothing to kill or remove, so they trigger an
error like this:

> Error response from daemon: Cannot kill container: something: No such container: something

and:

> Error: No such container: something

People often ask us if this is a problem, so instead of always having to
answer with "no, this is to be expected", we'd rather eliminate it now
and make logs cleaner.

In the event that:
- a container is really stuck and needs cleanup using kill/rm
- and cleanup fails, and we fail to report it because of error
suppression (`2>/dev/null`)

.. we'd still get an error when launching ("container name already in use .."),
so it shouldn't be too hard to investigate.
 2021-01-27 10:22:46 +02:00