-
Mark Goddard authored
The group variables originally in ansible/group_vars/ were playbook group variables, due to being adjacent to the playbooks. Typically they provided default values for global variables in the all group, as well as some more specific groups. This has worked fairly well, but results in (at least) a couple of problems. 1. The default variable precedence rules mean that these playbook group variables have a higher precedence than inventory group variables (for a given group). This can make it challenging to override playbook group variables in the inventory in Kayobe configuration. 2. Any playbook run by Kayobe must be in the same directory as the playbook group variables in order to use them. Given that they include variables required for connectivity such as ansible_host and ansible_user, this is quite critical. For Kayobe custom playbooks, we work around this by symlinking to the group_vars directory from the directory containing the custom playbook. This is not an elegant workaround, and has assumptions about the relative paths of the Kayobe configuration and virtual environment in which Kayobe is installed. Story: 2010280 Task: 46233 Change-Id: Ifea5c7e73f6f410f96a7398bfd349d1f631d9fc0
Mark Goddard authoredThe group variables originally in ansible/group_vars/ were playbook group variables, due to being adjacent to the playbooks. Typically they provided default values for global variables in the all group, as well as some more specific groups. This has worked fairly well, but results in (at least) a couple of problems. 1. The default variable precedence rules mean that these playbook group variables have a higher precedence than inventory group variables (for a given group). This can make it challenging to override playbook group variables in the inventory in Kayobe configuration. 2. Any playbook run by Kayobe must be in the same directory as the playbook group variables in order to use them. Given that they include variables required for connectivity such as ansible_host and ansible_user, this is quite critical. For Kayobe custom playbooks, we work around this by symlinking to the group_vars directory from the directory containing the custom playbook. This is not an elegant workaround, and has assumptions about the relative paths of the Kayobe configuration and virtual environment in which Kayobe is installed. Story: 2010280 Task: 46233 Change-Id: Ifea5c7e73f6f410f96a7398bfd349d1f631d9fc0
grafana 1.61 KiB
---
###############################################################################
# Grafana configuration.
# Grafana local admin user name. If you are deploying Monasca Grafana this
# should not conflict with an OpenStack user name.
grafana_local_admin_user_name: "grafana_local_admin"
# Path to git repo containing Grafana dashboards. Eg.
# https://github.com/stackhpc/grafana-reference-dashboards.git
grafana_monitoring_node_dashboard_repo:
# Dashboard repo version. Optional, defaults to 'HEAD'.
grafana_monitoring_node_dashboard_repo_version:
# Path to which Grafana dashboards will be cloned to a monitoring node
grafana_monitoring_node_dashboard_repo_checkout_path: "{{ source_checkout_path ~ '/grafana-dashboards' }}"
# The path, relative to the grafana_monitoring_node_dashboard_repo_checkout_path
# containing the dashboards. Eg. /prometheus/control_plane
grafana_monitoring_node_dashboard_repo_path:
# The Grafana organisation for the control plane. Note that for Monasca
# Grafana with domain support the format is:
# organisation_name@openstack_domain
grafana_control_plane_organisation: "{{ monasca_control_plane_project }}@{{ monasca_control_plane_domain }}"
# A dict of datasources to configure. See the stackhpc.grafana-conf role
# for all supported datasources. Example:
#
# grafana_datasources:
# monasca_api:
# port: 8082
# host: monasca-api
# monasca_log_api:
# port: 5607
# host: monasca-log-api
# elasticsearch:
# port: 9200
# host: monasca-elasticsearch
# project_id: "some_id"
#
grafana_datasources: {}
###############################################################################