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.
This commit introduces a new role that downloads and installs the
prometheus community postgres exporter https://github.com/prometheus-community/postgres_exporter.
A new credential is added to matrix_postgres_additional_databases that
allows the exporter access to the database to gather statistics.
A new dashboard was added to the grafana role, with some refactoring
to enable the dashboard only if the new role is enabled.
I've included some basic instructions for how to enable the role in
the Docs section.
In terms of testing, I've tested enabling the role, and disabling
it to make sure it cleans up the container and systemd role.
