Fluentd has a default timeout of 5s for flushing data to ElasticSearch.
If there is a significant backlog of unsent log messages, this timeout
can be exceeded, resulting in Fluentd failing to make further progress.
Raise the default timeout to 60s.
This patch adopts the configuration parameters previously proposed by
Krzysztof Klimonda.
Closes-Bug: #1983031
Closes-Bug: #1896611
Change-Id: I1aaab654a5a0752fccef2cfb8cc0bde4a0ee2562
clouds.yaml[0] is a richer way to express configuration for OpenStack
clouds. It's also fully supported by Ansible's OpenStack modules as
well as python-openstackclient and openstacksdk. It's the future - who
doesn't like the future?
Write a file using both the public (default) and the internal endpoints
for the admin user. Also, change all of the examples to reference it
and to get python-openstackclient to use it too.
[0] https://docs.openstack.org/openstacksdk/latest/user/guides/connect_from_config.html
Implements: blueprint use-clouds-yaml
Change-Id: I557d2e4975c7b3d3c713a556b9ba47af9567ce6e
Following up on [1].
The 3 variables are only introducing noise after we removed
the reliance on Keystone's admin port.
[1] I5099b08953789b280c915a6b7a22bdd4e3404076
Change-Id: I3f9dab93042799eda9174257e604fd1844684c1c
Adds a new configuration file that provides fluentd with an appropiate regex to match with OpenvSwitch logs in both default files.
The regex is segmented with variable as to isolate the relevant parts of each log message.
Closes-Bug: #1965815
Signed-off-by: Juan Pablo Suazo <jsuazo@whitestack.com>
Change-Id: Ife83c50c048d517a5c8a5dee588f8f7846fcee00
This project [1] can provide a one-stop solution to log collection,
cleaning, indexing, analysis, alarm, visualization, report generation
and other needs, which involves helping operator or maintainer to
quickly solve retrieve problems, grasp the operational health of the
platform, and improve the level of platform management.
[1] https://wiki.openstack.org/wiki/Venus
Change-Id: If3562bbed6181002b76831bab54f863041c5a885
After we remove the problematic, legacy "parser" plugin, the
config only needs the new, modern syntax.
This removes warnings that were logged.
Depends-On: https://review.opendev.org/c/openstack/kolla/+/823071
Change-Id: I33aa06de6ce88288769a8291ebd59e78e07cdbaf
To satisfy the needs of the modern parser plugin.
Needed-By: https://review.opendev.org/c/openstack/kolla/+/823071
Co-Authored-By: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: I2b748d0544c14bebefe8c62aa5aafaaa5371ce53
We stopped using this file in Queens
(https://review.opendev.org/494635), but the file was not removed at
that time.
Change-Id: Ibe5fb291e7c39965f5c4ff5ee4ea0bb1f8e6e9c2
Closes-Bug: #1840158
This change adds the dnsmasq.log for the ironic-dnsmasq container and
also enables more verbose logging when debug logging enabled.
This can be triggered globbaly via 'openstack_logging_debug' or per
service via 'ironic_logging_debug' or 'neutron_logging_debug'.
Change-Id: I0e6b089beb88827effbcc365625eb2df902f5470
Signed-off-by: Maksim Malchuk <maksim.malchuk@gmail.com>
chrony is not supported in Xena cycle, remove it from kolla
Moved tasks from chrony role to chrony-cleanup.yml playbook to avoid a
vestigial chrony role.
Co-Authored-By: Mark Goddard <mark@stackhpc.com>
Change-Id: I5a730d55afb49d517c85aeb9208188c81e2c84cf
Currently only operations done with default kolla_toolbox user are logged
to /var/log/kolla/ansible.log.
In order to fix logging, permissions to ansible.log must allow writing
for other users in kolla group - and then a separate patch will follow
to make custom ansible.cfg file usable by other toolbox users.
Partial-Bug: #1942846
Change-Id: I1be60ac7647b1a838e97f05f15ba5f0e39e8ae3c
Certain overrides for rabbitmq may need to be set for `rabbitmqctl` in
kolla-toolbox aswell.
This commit allows to override `rabbitmq-env.conf` and `erl_inetrc` in
kolla-toolbox.
Change-Id: Idef6adcf9700f75a2db503444a8de093ee21a9c5
This patch adds support for integrating Prometheus with Fluentd.
This can be used to extract useful information about the status
of Fluentd, such as output buffer capacity and logging rate,
and also to extract metrics from logs via custom Fluentd
configuration. More information can be found here in [1].
[1] https://docs.fluentd.org/monitoring-fluentd/monitoring-prometheus
Change-Id: I233d6dd744848ef1f1589a462dbf272ed0f3aaae
By default, Ansible injects a variable for every fact, prefixed with
ansible_. This can result in a large number of variables for each host,
which at scale can incur a performance penalty. Ansible provides a
configuration option [0] that can be set to False to prevent this
injection of facts. In this case, facts should be referenced via
ansible_facts.<fact>.
This change updates all references to Ansible facts within Kolla Ansible
from using individual fact variables to using the items in the
ansible_facts dictionary. This allows users to disable fact variable
injection in their Ansible configuration, which may provide some
performance improvement.
This change disables fact variable injection in the ansible
configuration used in CI, to catch any attempts to use the injected
variables.
[0] https://docs.ansible.com/ansible/latest/reference_appendices/config.html#inject-facts-as-vars
Change-Id: I7e9d5c9b8b9164d4aee3abb4e37c8f28d98ff5d1
Partially-Implements: blueprint performance-improvements
