These three roles have multiple variable prefixes each:
- kakaotalk: matrix_appservice_kakaotalk + matrix_appservice_kakaotalk_node
- telegram: matrix_mautrix_telegram + matrix_mautrix_telegram_lottieconverter
- synapse: matrix_synapse + matrix_synapse_customized + matrix_synapse_rust_synapse_compress_state
For each: renamed _docker_image* to _container_image* (and _docker_src*,
_docker_repo* where applicable), added deprecation entries in
validate_config.yml, updated group_vars references, and moved
deprecation tasks to the front of validate_config.yml.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
For each of the 34 roles (3 clients, 9 bots, 22 bridges), this commit:
- Adds `_restart_necessary: false` default variable
- Adds `register:` directives to config/image/systemd tasks
- Computes `_restart_necessary` via set_fact (OR of all .changed results)
- Wires `(_restart_necessary | bool)` in group_vars/matrix_servers
This allows the systemd service manager to skip unnecessary restarts
when running install-* tags and nothing actually changed.
Service roles and complex multi-service roles will follow separately.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
These variables track whether a database migration necessitates a service
restart. The new name avoids confusion with the conditional restart
feature introduced in af193043/9accc848/4a8df138, where
devture_systemd_service_manager handles restarting services whose
configuration or image changed. The old _requires_restart name was
ambiguous — it could be mistaken for the systemd_service_manager
mechanism — so _migration_requires_restart makes the purpose explicit.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* Add matrix_bridges_msc4190_enabled flag for using msc4190 on supported mautrix bridges.
* Apply to_json to msc4190 in mautrix configs
* Add | to_json to mautrix bridge registration io.element.msc4190.
* require matrix_synapse_experimental_features_msc3202_device_masquerading_enabled for matrix_bridges_msc4190_enabled
* Also add msc4190 support for mautrix-telegram
`matrix_container_global_registry_prefix_override` may look similar to
the old `matrix_container_global_registry_prefix` variable
(removed in d6bf789710), but it's different.
The old `matrix_container_global_registry_prefix` variable was just a hardcode of `docker.io/` and roles that
needed to refer to `docker.io/` could use it. However, this was:
- not used by all roles, because some need another registry (not `docker.io/`)
- used only by roles within the playbook (`roles/custom`), not external roles
Overriding the old `matrix_container_global_registry_prefix` variable was rather pointless,
as it didn't cover everything.
The new `matrix_container_global_registry_prefix_override` variable, on the other hand,
lets you override the registry prefix for all components, regardless of whether they
use `docker.io/` or another registry by default.
This is useful to people who have somehow mirrored all container images to their own registry,
as it provides them with a single variable they can flip to influence the whole playbook.
This:
- brings consistency - no more mixing `_name_prefix` and `_registry_prefix`
- adds extensibility - a future patch will allow reconfiguring all registry prefixes for all roles in the playbook
We still have `_docker_` vs `_container_` inconsistencies.
These may be worked on later.
* Add a global config option for Docker network MTU
* Upgrade systemd_docker_base (v1.2.0-0 -> v1.3.0-0)
The new version includes `devture_systemd_docker_base_container_networks_driver_options`
due to 3cc7d12396
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3502
* Switch from passing matrix_playbook_docker_network_mtu to respecting devture_systemd_docker_base_container_networks_driver_options
Related to:
- 3cc7d12396
- https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3502
* Update all roles to versions that respect `devture_systemd_docker_base_container_networks_driver_options`
---------
Co-authored-by: Slavi Pantaleev <slavi@devture.com>
We'be already been going against upstream defaults and have been
enabling backfilling for a few other bridges (Messenger, Instagram, Telegram, Twitter).
Now I'm enabling backfilling by default for the remaining ones, for
consistency.
Related to 0241c71a4c
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3270#issuecomment-2143782962
With this change, it should be possible for people to adjust the Docker
dependency from `docker.service` to something else (e.g. `pkg-ContainerManager-dockerd.service`),
or to completely eliminate it by setting `devture_systemd_docker_base_docker_service_name` to an empty string.
This makes it easier for people to use the playbook against a Synology DSM server.
commit cf8637efac
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Mar 24 19:14:57 2024 +0200
Make devture_systemd_docker_base_ipv6_enabled automatically reconfigure geerlingguy/ansible-role-docker
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3218
commit dc7af3bc7d
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Mar 24 19:10:31 2024 +0200
Replace matrix_ipv6_enabled with devture_systemd_docker_base_ipv6_enabled
Related to https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/3218
commit 07e900d6a2
Author: Slavi Pantaleev <slavi@devture.com>
Date: Sun Mar 24 19:01:51 2024 +0200
Improve matrix_ipv6_enabled comments
commit 3f03ca7f69
Author: Tilo Spannagel <development@tilosp.de>
Date: Sat Mar 9 19:27:50 2024 +0000
Add setting to enable ipv6
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.
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.
Slavi Pantaleev
QEDeD
renovate[bot]
Onestacked
Suguru Hirahara
David Mehren
gardar
Pierre 'McFly' Marty
Aine
Samuel Meenzen
Aine