Refactor that prepares kolla_container_facts
module for introducing more actions that will be moved
from kolla_container module and kolla_container_volume_facts.
This change is based on a discussion about adding a new action
to kolla_container module that retrieves all names of the running
containers. It was agreed that kolla-ansible should follow Ansible's
direction of splitting modules between action modules and facts
modules. Because of this, kolla_container_facts needs to be able
to handle different requests for data about containers or volumes.
Change-Id: Ieaec8f64922e4e5a2199db2d6983518b124cb4aa
Signed-off-by: Ivan Halomi <ivan.halomi@tietoevry.com>
Most roles are not leveraging the jinja filters available.
According to [1] filtering the list of services makes the execution
faster than skipping the tasks.
This patchset also includes some cosmetic changes to genconfig.
Individual services are now also using a jinja filter. This has
no impact on performance, just makes the tasks look cleaner.
Naming of some vars in genconfig was changed to "service" to make
the tasks more uniform as some were previously using
the service name and some were using "service".
Three metrics from the deployment were taken and those were
- overall deployment time [s]
- time spent on the specific role [s]
- CPU usage (measured with perf) [-]
Overall genconfig time went down on avg. from 209s to 195s
Time spent on the loadbalancer role went down on avg. from 27s to 23s
Time spent on the neutron role went down on avg from 102s to 95s
Time spent on the nova-cell role went down on avg. from 54s to 52s
Also the average CPUs utilized reported by perf went down
from 3.31 to 3.15.
For details of how this was measured see the comments in gerrit.
[1] - https://github.com/stackhpc/ansible-scaling/blob/master/doc/skip.md
Change-Id: Ib0f00aadb6c7022de6e8b455ac4b9b8cd6be5b1b
Signed-off-by: Roman Krček <roman.krcek@tietoevry.com>
This new role will handle setting sysctl values.
It also handles cases when IPv6 setting is changed, but IPv6 is
not enabled on the system by skipping those settings.
This is an augmentation of previous patch:
Icccfc1c509179c3cfd59650b7917a637f9af9646
Related-bug: #1906306
Change-Id: I5d6cda3307b3d2f27c1b2995f28772523b203fe7
Signed-off-by: Roman Krček <roman.krcek@tietoevry.com>
This way the playbooks won't try to set ipv6 systemctl options
unless ipv6 is available on the system.
Closes-bug: #1906306
Change-Id: Icccfc1c509179c3cfd59650b7917a637f9af9646
HAProxy exposes a Prometheus metrics endpoint, it just needs to be
enabled. Enable this and remove configuration for
prometheus-haproxy-exporter. Remaining prometheus-haproxy-exporter
containers will automatically be removed.
Change-Id: If6e75691d2a996b06a9b95cb0aae772db54389fb
Co-Authored-By: Matt Anson <matta@stackhpc.com>
Changes name of ansible module kolla_docker to
kolla_container.
Change-Id: I13c676ed0378aa721a21a1300f6054658ad12bc7
Signed-off-by: Martin Hiner <m.hiner@partner.samsung.com>
Threads are the recommended way to scale CPU performance since HAProxy
1.8.
Official documentation says: « While "nbproc" historically used to be the only
way to use multiple processors, it also involved a number of shortcomings
related to the lack of synchronization between processes (health-checks, peers,
stick-tables, stats, ...) which do not affect threads. As such, any modern
configuration is strongly encouraged to migrate away from "nbproc" to
"nbthread". ».
Change-Id: I6f2e9d74e68703c8e0827e495945a75f020e1561
The directive used has the same semantic as what is done above for nbproc > 1:
it binds each thread to a CPU. It is simpler and does not require a loop because
it uses the auto: syntax available in HAProxy 2.4.
Change-Id: I1ce124b678140f5f4737df557683bb67bc7cfc66
Threads are the recommended way to scale CPU performance since HAProxy
1.8.
Official documentation says: « While "nbproc" historically used to be the only
way to use multiple processors, it also involved a number of shortcomings
related to the lack of synchronization between processes (health-checks, peers,
stick-tables, stats, ...) which do not affect threads. As such, any modern
configuration is strongly encouraged to migrate away from "nbproc" to
"nbthread". ».
While more recent versions of HAProxy automatically detect the number of
available CPU and enable threads for them, it can be useful to explicitely set
the value.
In this patch, setting cpu-map for threads is not supported.
Change-Id: Id917c70f3dbe52f24f25d9403ba8151729e8966b
Use case: exposing single external https frontend and
load balancing services using FQDNs.
Support different ports for internal and external endpoints.
Introduced kolla_url filter to normalize urls like:
- https://magnum.external:443/v1
- http://magnum.external:80/v1
Change-Id: I9fb03fe1cebce5c7198d523e015280c69f139cd0
Co-Authored-By: Jakub Darmach <jakub@stackhpc.com>
We've seen issues in CI when keepalived haproxy check script returns
an error and keepalived is switching to backup and then again to primary
on a single node environment.
Closes-Bug: #2025219
Change-Id: Iba62e76b3cf83f3ade6df81288d2d77129ffc725
When running in check mode, some prechecks previously failed because
they use the command module which is silently not run in check mode.
Other prechecks were not running correctly in check mode due to e.g.
looking for a string in empty command output or not querying which
containers are running.
This change fixes these issues.
Closes-Bug: #2002657
Change-Id: I5219cb42c48d5444943a2d48106dc338aa08fa7c
assert will also fail when we're not meeting the conditions, makes
clear what we're actually testing, and isn't listed as a skipped task
when the condition is ok.
Change-Id: Ia72c7052d7f9b8c7d86d74a15dcd9e003178972b
Regularly, we experience issues in Kolla Ansible deployments because we
use wrong options in OpenStack configuration files. This is because
OpenStack services ignore unknown options. We also need to keep on top
of deprecated options that may be removed in the future. Integrating
oslo-config-validator into Kolla Ansible will greatly help.
Adds a shared role to run oslo-config-validator on each service. Takes
into account that services have multiple containers, and these may also
use multiple config files. Service roles are extended to use this shared
role. Executed with the new command ``kolla-ansible validate-config``.
Change-Id: Ic10b410fc115646d96d2ce39d9618e7c46cb3fbc
This change replaces ElasticSearch with OpenSearch, and Kibana
with OpenSearch Dashboards. It migrates the data from ElasticSearch
to OpenSearch upon upgrade.
No TLS support is in this patch (will be a followup).
A replacement for ElasticSearch Curator will be added as a followup.
Depends-On: https://review.opendev.org/c/openstack/kolla/+/830373
Co-authored-by: Doug Szumski <doug@stackhpc.com>
Co-authored-by: Kyle Dean <kyle@stackhpc.com>
Change-Id: Iab10ce7ea5d5f21a40b1f99b28e3290b7e9ce895
Kolla Ansible is switching to OpenSearch and is dropping support for
deploying ElasticSearch. This is because the final OSS release of
ElasticSearch has exceeded its end of life.
Monasca is affected because it uses both Logstash and ElasticSearch.
Whilst it may continue to work with OpenSearch, Logstash remains an
issue.
In the absence of any renewed interest in the project, we remove
support for deploying it. This helps to reduce the complexity
of log processing configuration in Kolla Ansible, freeing up
development time.
Change-Id: I6fc7842bcda18e417a3fd21c11e28979a470f1cf
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 variable to kolla_container_facts
module, this prepares module to be used with docker and podman as well
without further changes in roles.
Signed-off-by: Ivan Halomi <i.halomi@partner.samsung.com>
Co-authored-by: Martin Hiner <m.hiner@partner.samsung.com>
Change-Id: I9e8fa30646844ab4a288555f3aafdda345b3a118
First part of patchset:
https://review.opendev.org/c/openstack/kolla-ansible/+/799229/
in which was suggested to split patch into smaller ones.
This implements kolla_container_engine variable
in command calls of docker,so later on it can be
also used for podman without further change.
Signed-off-by: Ivan Halomi <i.halomi@partner.samsung.com>
Change-Id: Ic30b67daa2e215524096ad1f4385c569e3d41b95
By default ProxySQL's default value of max_replication_lag
is 0 which is in fact disabling this feature [1].
If it is greater than 0, ProxySQL will regularly monitor
replication lag and if it goes beyond the configured threshold
it will temporary shun the host until replication catches up.
This should be configurable via kolla-ansible as every
openstack deployment can be different in terms of network
delays, database load etc.. , so user should have option
to configure when database backend will be shunned.
[1] https://proxysql.com/documentation/main-runtime/
Change-Id: I66171638abc712cb84b380042f1d29f54c499e73
With the handler in the haproxy-config role, it gets triggered once for
every service that changes the firewall config. This happens because the
role is included dynamically. If we move the handler to the haproxy
role, which is only included once, the handler will trigger at most
once.
This is a follow up for Iea3680142711873984efff2b701347b6a56dd355.
Change-Id: Iad9ed241026435085bc9a0f5802818010b47830f
Kolla environment currently uses haproxy
to fullfill HA in mariadb. This patch
is switching haproxy to proxysql if enabled.
This patch is also replacing mariadb's user
'haproxy' with user 'monitor'. This replacement
has two reasons:
- Use better name to "monitor" galera claster
as there are two services using this user
(HAProxy, ProxySQL)
- Set password for monitor user as it's
always better to use password then not use.
Previous haproxy user didn't use password
as it was historically not possible with
haproxy and mariadb-clustercheck wasn't
implemented.
Depends-On: https://review.opendev.org/c/openstack/kolla/+/769385
Depends-On: https://review.opendev.org/c/openstack/kolla/+/765781
Depends-On: https://review.opendev.org/c/openstack/kolla/+/850656
Change-Id: I0edae33d982c2e3f3b5f34b3d5ad07a431162844
This change introduces automated configuration of firewalld and adds
a new filter for extracting services from the project_services dict.
the filter selects any enabled services and their haproxy element
and returns them so they can be iterated over.
This commit also enables automated configuration of firewalld from enabled
openstack services and adds them to the defined zone and reloads the
system firewall.
Change-Id: Iea3680142711873984efff2b701347b6a56dd355
We need this to be stop-start as haproxy and proxysql need to be
reconfigured simultaneously when switching between them.
This change also introduces checks for service enablement.
Co-Authored-By: Radosław Piliszek <radoslaw.piliszek@gmail.com>
Change-Id: I2e10f490305f3d8b1b7abbc66ddb40df65c37fe7
