This is consistent with what all other roles do. If someone includes a
role, the assumption is that they want its functionality enabled.
The playbook distribution then disables components via
`group_vars/matrix_servers`. We've always had `matrix_grafana_enabled: false`
there, so flipping the in-role `_enabled` flag to `true` does not change
anything for playbook users. Users who import the roles individually in
their own other playbooks (and who don't use `group_vars/matrix_servers`)
may observe a change in the defaults with this.
Using `matrix_synapse_*` variables within the `matrix-grafana` role
is not a good practice.
We now have a `matrix_grafana_default_home_dashboard_path` variable
with a good universal default value and we override it via
`group_vars/matrix_servers` based on enabled components, etc.
This is a better fix for https://github.com/spantaleev/matrix-docker-ansible-deploy/pull/2133
We shouldn't be using it in the role (`tasks/setup.yml`) without
defining at least some default value in the role itself.
We've always had the override in `group_vars/matrix_servers`,
so the variable was essentially defined (at the playbook level), but
that's not the right way to do things.
People often report and ask about these "failures".
More-so previously, when the `docker kill/rm` output was collected,
but it still happens now when people do `systemctl status
matrix-something` and notice that it says "FAILURE".
Suppressing to avoid further time being wasted on saying "this is
expected".
Reverts b1b4ba501f, 90c9801c56, a3c84f78ca, ..
I haven't really traced it (yet), but on some servers, I'm observing
`ansible-playbook ... --tags=start` completing very slowly, waiting
to stop services. I can't reproduce this on all Matrix servers I manage.
I suspect that either the systemd version is to blame or that some
specific service is not responding well to some `docker kill/rm` command.
`ExecStop` seems to work great in all cases and it's what we've been
using for a very long time, so I'm reverting to that.
Until now, we were leaving services "enabled"
(symlinks in /etc/systemd/system/multi-user.target.wants/).
We clean these up now. Broken symlinks may still exist in older
installations that enabled/disabled services. We're not taking care
to fix these up. It's just a cosmetic defect anyway.
Aine