- Jan 24, 2025
-
-
Jakub Darmach authored
Fixed Grafana role tasks failing when running with Ansible check mode enabled. Closes-Bug: 2095592 Change-Id: Ibe5a132e109bc46ab7875b70f8357a2f580f931e (cherry picked from commit b59fe6cc)
-
- Jun 10, 2024
-
-
Jan Horstmann authored
Task `Check if extra configuration file exists` picks up all files in `{{ node_custom_config }}/grafana` including those that get handled specially later on. While `prometheus.yml` and `provisioning.yml` are best excluded from extra config , because their treatment requires more than just copying, `grafana_home_dashboard.json` may simply be treated as extra config, which saves the execution of two additional tasks. Closes-Bug: 2067999 Change-Id: I7bce1fe3d0a96816f1782107b202d6dac7d1291d Signed-off-by:
Jan Horstmann <horstmann@osism.tech>
-
- Feb 12, 2024
-
-
Dawud authored
Fixes not being able to add additional plugins at build time due to the `grafana` volume being mounted over the existing `/var/lib/grafana` directory. This is fixed by copying the dashboards into the container from an existing bind mount instead of using the ``grafana`` volume. This however leaves behind the volume which should be removed with `docker volume rm grafana` or by setting `grafana_remove_old_volume` to `True`. Closes-Bug: #2039498 Change-Id: Ibcffa5d8922c470f655f447558d4a9c73b1ba361
-
- Nov 04, 2022
-
-
Ivan Halomi authored
Second part of patchset: https://review.opendev.org/c/openstack/kolla-ansible/+/799229/ in which was suggested to split patch into smaller ones. THis change adds container_engine to module parameters so when we introduce podman, kolla_toolbox can be used for both engines. Signed-off-by:
Ivan Halomi <i.halomi@partner.samsung.com> Co-authored-by:
Martin Hiner <m.hiner@partner.samsung.com> Change-Id: Ic2093aa9341a0cb36df8f340cf290d62437504ad
-
- Jul 25, 2022
-
-
Michal Nasiadka authored
ansible-lint introduced var-spacing - let's fix our code. Change-Id: I0d8aaf3c522a5a6a5495032f6dbed8a2be0251f0
-
- Aug 19, 2020
-
-
Rafael Weingärtner authored
The goal for this push request is to normalize the construction and use of internal, external, and admin URLs. While extending Kolla-ansible to enable a more flexible method to manage external URLs, we noticed that the same URL was constructed multiple times in different parts of the code. This can make it difficult for people that want to work with these URLs and create inconsistencies in a large code base with time. Therefore, we are proposing here the use of "single Kolla-ansible variable" per endpoint URL, which facilitates for people that are interested in overriding/extending these URLs. As an example, we extended Kolla-ansible to facilitate the "override" of public (external) URLs with the following standard "<component/serviceName>.<companyBaseUrl>". Therefore, the "NAT/redirect" in the SSL termination system (HAproxy, HTTPD or some other) is done via the service name, and not by the port. This allows operators to easily and automatically create more friendly URL names. To develop this feature, we first applied this patch that we are sending now to the community. We did that to reduce the surface of changes in Kolla-ansible. Another example is the integration of Kolla-ansible and Consul, which we also implemented internally, and also requires URLs changes. Therefore, this PR is essential to reduce code duplicity, and to facility users/developers to work/customize the services URLs. Change-Id: I73d483e01476e779a5155b2e18dd5ea25f514e93 Signed-off-by:
Rafael Weingärtner <rafael@apache.org>
-
- Jun 15, 2020
-
-
Radosław Piliszek authored
Grafana changed the error message wording. Match on the shortest sane string to play it safe. Change-Id: Ic175ebdb1da6ef66047309ff07bcbba98fc67008 Closes-Bug: #1881890
-
- Feb 22, 2020
-
-
James Kirsch authored
Service configuration urls should be constructed using kolla_internal_fqdn instead of kolla_internal_vip_address. Otherwise SSL validation will fail when certificates are issued using domain names. Change-Id: I21689e22870c2f6206e37c60a3c33e19140f77ff Closes-Bug: 1862419
-
- Jan 28, 2020
-
-
James Kirsch authored
Delegate executing uri REST methods to the current module containers using kolla_toolbox. This will allow self signed certificate that are already copied into the container to be automatically validated. This circumvents requiring Kolla Ansible to explicitly disable certificate validation in the ansible uri module. Partially-Implements: blueprint custom-cacerts Change-Id: I2625db7b8000af980e4745734c834c5d9292290b
-
- Oct 16, 2019
-
-
Radosław Piliszek authored
Introduce kolla_address filter. Introduce put_address_in_context filter. Add AF config to vars. Address contexts: - raw (default): <ADDR> - memcache: inet6:[<ADDR>] - url: [<ADDR>] Other changes: globals.yml - mention just IP in comment prechecks/port_checks (api_intf) - kolla_address handles validation 3x interface conditional (swift configs: replication/storage) 2x interface variable definition with hostname (haproxy listens; api intf) 1x interface variable definition with hostname with bifrost exclusion (baremetal pre-install /etc/hosts; api intf) neutron's ml2 'overlay_ip_version' set to 6 for IPv6 on tunnel network basic multinode source CI job for IPv6 prechecks for rabbitmq and qdrouterd use proper NSS database now MariaDB Galera Cluster WSREP SST mariabackup workaround (socat and IPv6) Ceph naming workaround in CI TODO: probably needs documenting RabbitMQ IPv6-only proto_dist Ceph ms switch to IPv6 mode Remove neutron-server ml2_type_vxlan/vxlan_group setting as it is not used (let's avoid any confusion) and could break setups without proper multicast routing if it started working (also IPv4-only) haproxy upgrade checks for slaves based on ipv6 addresses TODO: ovs-dpdk grabs ipv4 network address (w/ prefix len / submask) not supported, invalid by default because neutron_external has no address No idea whether ovs-dpdk works at all atm. ml2 for xenapi Xen is not supported too well. This would require working with XenAPI facts. rp_filter setting This would require meddling with ip6tables (there is no sysctl param). By default nothing is dropped. Unlikely we really need it. ironic dnsmasq is configured IPv4-only dnsmasq needs DHCPv6 options and testing in vivo. KNOWN ISSUES (beyond us): One cannot use IPv6 address to reference the image for docker like we currently do, see: https://github.com/moby/moby/issues/39033 (docker_registry; docker API 400 - invalid reference format) workaround: use hostname/FQDN RabbitMQ may fail to bind to IPv6 if hostname resolves also to IPv4. This is due to old RabbitMQ versions available in images. IPv4 is preferred by default and may fail in the IPv6-only scenario. This should be no problem in real life as IPv6-only is indeed IPv6-only. Also, when new RabbitMQ (3.7.16/3.8+) makes it into images, this will no longer be relevant as we supply all the necessary config. See: https://github.com/rabbitmq/rabbitmq-server/pull/1982 For reliable runs, at least Ansible 2.8 is required (2.8.5 confirmed to work well). Older Ansible versions are known to miss IPv6 addresses in interface facts. This may affect redeploys, reconfigures and upgrades which run after VIP address is assigned. See: https://github.com/ansible/ansible/issues/63227 Bifrost Train does not support IPv6 deployments. See: https://storyboard.openstack.org/#!/story/2006689 Change-Id: Ia34e6916ea4f99e9522cd2ddde03a0a4776f7e2c Implements: blueprint ipv6-control-plane Signed-off-by:
Radosław Piliszek <radoslaw.piliszek@gmail.com>
-
- Apr 20, 2019
-
-
chenxing authored
20 seconds may be too short to wait for grafana ready, Let's keep the check task 60 seconds. backport: rocky Change-Id: Ib219ad215d1ef2147ba3591f8c398feb4f3c8888 Closes-Bug: #1821285
-
- Feb 19, 2018
-
-
Doug Szumski authored
The grafana local admin username can be configured by overriding the admin user field in the grafana.ini file. However, this will fail when kolla-ansible attempts to configure any enabled datasources for grafana because the local admin password is hardcoded to 'admin'. This change allows the grafana local admin password to be configured via group vars so that the correct username is used when configuring datasources. Closes-Bug: #1750408 Change-Id: I0962200894f7a0452da1c249a68f9230b6fab13f
-
- Jan 24, 2018
-
-
Doug Szumski authored
If the wrong status code is returned, ansible sets failed: true. This means that a retry is never attempted. Use .get('status') to work around the possibility that a status may not be returned in some corner cases. For example: TASK [grafana : Wait for grafana application ready] ***************** fatal: [some_remote_node]: FAILED! => {"failed": true, "msg": "The conditional check 'result.status == 200' failed. The error was: error while evaluating conditional (result.status == 200): 'dict object' has no attribute 'status'"} Change-Id: I14207d1a9e994fa25c1c061025fff5b64a71d690 Closes-Bug: #1742501
-
- Jan 11, 2018
-
-
Doug Szumski authored
Following deployment of Grafana, a check is made to ensure that the login page is accessible. If the Grafana container has been deployed to a remote host, but is not directly accessible over the deployment network then the check will fail because the task is set to run with connection: local. For example, if Ansible is using a different network to the network on which grafana is exposed to connect to the remote host then the task may fail. A similar problem exists for the remaining two tasks in the post_config file. Further to this, if Grafana is not accessible, the ansible uri module does not return a status field, so no retry attempts are made and the task fails with an obscure message: TASK [grafana : Wait for grafana application ready] ***************** fatal: [some_remote_node]: FAILED! => {"failed": true, "msg": "The conditional check 'result.status == 200' failed. The error was: error while evaluating conditional (result.status == 200): 'dict object' has no attribute 'status'"} $ ansible --version ansible 2.3.2.0 config file = /etc/ansible/ansible.cfg configured module search path = Default w/o overrides python version = 2.7.5 (default, Aug 4 2017, 00:39:18) [GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] Change-Id: I77e2129b4a1c5f2f0802fb92eb03395ff72cf5f3 Closes-Bug: #1742501
-
- Aug 16, 2017
-
-
guochao authored
I think that we do not need this in a production-ready project. Change-Id: Ief1392c5e8becc90034fca782211a1da30da14ae
-
- Jul 24, 2017
-
-
Mathias Ewald authored
Check grafana's /login url for status code 200 instead of root url since the latter does not return an http 200 code Change-Id: Ide7da26c0e217a4a60ad3d2ac693d6f7ac7bb722 Closes-Bug: #1705911
-
- Jul 21, 2017
-
-
Mathias Ewald authored
Make data source creation more dynamic to support a variable number of data source of different types Only create data sources actually deployed by kolla Change-Id: I26a2d3c71b178562b906623ab77eaff673c81dce
-
- Jun 12, 2017
-
-
Bertrand Lallau authored
Sometimes the "Enable influxdb datasource" task failed with "503 Service Unavailable" error. Waiting for grafana port UP seems not always enough, it requires to wait for application ready. Change-Id: I3a27b3086698b89a80a3f585beb810831289ae7a Closes-Bug: #1697213
-
- Jun 02, 2017
-
-
Bertrand Lallau authored
Recently added post_config for Grafana does some uri queries, these can be problematic if run across every node. Change-Id: I580212474879da18780fc5f66a21952a9e6f8daa
-
- Apr 25, 2017
-
-
Bertrand Lallau authored
In order to automate Grafana configuration, this fix automatically set the InfluxDB datasource. This avoid doing a annoying manual configuration after Kolla-ansible deployment. Change-Id: I2b1a63fd371966192f1df0a82cee4711c6324710
-