Perhaps it would be better to download once and for all the GPG key and store it in the repo?
At least, it seems important to set validate_certs: true.
Perhaps it would be better to download once and for all the GPG key and store it in the repo?
At least, it seems important to set `validate_certs: true`.
I personally don't like this way of partially configuring applications via Ansible.
I strongly prefer a template to deploy the entire grafana.ini file.
I find it much more readable (and more consistent for configuration files in a format that doesn't have a module like ini_file).
Furthermore, it guarantees the totality of the application's behaviour, and avoids having inconsistent configurations.
Nevertheless, I welcome pro-ini_file arguments.
I personally don't like this way of partially configuring applications via Ansible.
I strongly prefer a `template` to deploy the entire `grafana.ini` file.
I find it much more readable (and more consistent for configuration files in a format that doesn't have a module like `ini_file`).
Furthermore, it guarantees the totality of the application's behaviour, and avoids having inconsistent configurations.
Nevertheless, I welcome pro-`ini_file` arguments.
Grafana configuration files evolve fast, it garantees that we are not replacing it with an older version.
Even if the targetted format is not supported by an Ansible module, you can always revert to lineinfile module which is able to replace a line with constraints.
Keeping small changes to the original file garantee better readability during APT upgrades.
Personnaly I hate ini_file and template. I would much rather prefer to not touch the sane defaults and just place an extra file with the configuration that is specific to Aurore. Because Grafana was not packaged by a Debian maintainer, it does not have the usual patch to add a conf.d directory to drop extra configuration.
Taking that into account, I would go for these choice (we need to discuss that):
For well-packaged software, let's just place files in conf.d or site-enabled folders without touching any other files if possible.
For packages that have their configuration moving fast (e.g. Gitlab, Grafana), let's use lineinfile or a specialized equivalent.
For stable packages that does not have .d folders, let's commit the original configuration as a template.
Pro-ini_file arguments:
* Grafana configuration files evolve fast, it garantees that we are not replacing it with an older version.
* Even if the targetted format is not supported by an Ansible module, you can always revert to `lineinfile` module which is able to replace a line with constraints.
* Keeping small changes to the original file garantee better readability during APT upgrades.
Personnaly I hate `ini_file` and `template`. I would much rather prefer to not touch the sane defaults and just place an extra file with the configuration that is specific to Aurore. Because Grafana was not packaged by a Debian maintainer, it does not have the usual patch to add a `conf.d` directory to drop extra configuration.
Taking that into account, I would go for these choice (we need to discuss that):
* For well-packaged software, let's just place files in `conf.d` or `site-enabled` folders without touching any other files if possible.
* For packages that have their configuration moving fast (e.g. Gitlab, Grafana), let's use `lineinfile` or a specialized equivalent.
* For stable packages that does not have `.d` folders, let's commit the original configuration as a template.
@ -0,0 +11,4 @@apt_key:url: https://packages.grafana.com/gpg.keystate: presentvalidate_certs: falsePerhaps it would be better to download once and for all the GPG key and store it in the repo?
At least, it seems important to set
validate_certs: true.@ -0,0 +30,4 @@retries: 3until: apt_result is succeeded- name: Configure GrafanaI personally don't like this way of partially configuring applications via Ansible.
I strongly prefer a
templateto deploy the entiregrafana.inifile.I find it much more readable (and more consistent for configuration files in a format that doesn't have a module like
ini_file).Furthermore, it guarantees the totality of the application's behaviour, and avoids having inconsistent configurations.
Nevertheless, I welcome pro-
ini_filearguments.Pro-ini_file arguments:
lineinfilemodule which is able to replace a line with constraints.Personnaly I hate
ini_fileandtemplate. I would much rather prefer to not touch the sane defaults and just place an extra file with the configuration that is specific to Aurore. Because Grafana was not packaged by a Debian maintainer, it does not have the usual patch to add aconf.ddirectory to drop extra configuration.Taking that into account, I would go for these choice (we need to discuss that):
conf.dorsite-enabledfolders without touching any other files if possible.lineinfileor a specialized equivalent..dfolders, let's commit the original configuration as a template.@ -0,0 +94,4 @@value: "{{ grafana.database.user }}"- section: databaseoption: passwordvalue: "{{ grafana.database.password }}"Where are Grafana logs sent?
It seems to be
/var/log/grafana.log, when it should be either syslog or journald.It's also in journal, see
sudo journalctl -xe -u grafana-server. Should I ask grafana to NOT log into/var/log/grafana/grafana.log?90a6e6acf0tofdfed1a05a3 years ago00d63cf082into master 3 years ago00d63cf082.