Depends-On: https://review.opendev.org/c/openstack/kolla/+/782815
Change-Id: I5230f017f1fa99629b81d944ba245c5778411b1f

For using 3rd party Octavia providers (such as OVN provider) an
octavia-driver-agent container must be running to expose those providers to
use.

OVN CI job has been extended with deploying Octavia and testing OVN Load
Balancer.

Closes-Bug: #1903506
Depends-On: https://review.opendev.org/c/openstack/kolla/+/771191

Change-Id: Ibafa8b7307981f2a51e630cc113d18af6162171c

Allow users to import custom grafana dashboards.
Dashboards as JSON files should be placed into
"{{ node_custom_config }}/grafana/dashboards/" folder.

Change-Id: Id0f83b8d08541b3b74649f097b10c9450201b426

ELK 7 requires some minor changes from the existing ELK 6 config.

Depends-On: Icfa3db5788b25f70ee75411dbaf20d8d4a6a734b
Change-Id: I9815d202a77da0477aea43d714a5def8a24724fa

The rabbitmq_prometheus plugin is available in RabbitMQ 3.8.

https://www.rabbitmq.com/prometheus.html



Implements: blueprint rabbitmq-prometheus
Co-Authored-By: Mark Goddard <mark@stackhpc.com>
Change-Id: I4d69a93a6c70db8d40626042cdbe773747b238ae

This trivial patch is just turning off ansible
changed report for group_by tasks as it could
be confusing for user.

Change-Id: I7512af573782359a6f01290a55291ac7eb0de867

Docker is using 172.17.0.0/16 by default for bridge networking on
docker0, and this might cause routing problems for operator networks.

This change introduces docker_disable_default_network to disable the
bridge networking by putting "bridge: none"[1] to daemon.json

Bridge networking does not work without iptables, so we set the default
for docker_disable_default_network to
docker_disable_default_iptables_rules.

For better defaults, this feature will be enabled by default in
Wallaby.

[1] https://docs.docker.com/engine/reference/commandline/dockerd/

Change-Id: Ic745300b27e50132d80d03787fa4abfada2d0173
Closes-Bug: #1848249
Related-Bug: #1849275

In order to disable libvirt debug in CI (which takes vast amount of storage)
this change introduces nova_libvirt_logging_debug and disables that in CI.

Change-Id: I90bfd1b300ad3202ea4d139fda6d6beb44c5820f

According the documentation [1] there need to configure auth_uri in the
[filter:s3token] section instead of www_authenticate_uri which cause an
error 'swift.common.wsgi.ConfigFileError: Invalid auth_uri; must
include scheme and host' during start the swift-proxy-server container.

1. https://docs.openstack.org/swift/ussuri/middleware.html#s3-token-middleware



Change-Id: I6b8f5807ebb746428a501dca13eae30763dede8d
Closes-Bug: 1862765
Signed-off-by: Maksim Malchuk <maksim.malchuk@gmail.com>

use User and Group in octavia-interface service.
this way looks more graceful

this change also fix the octavia-interface does not restart
when the octavia-interface.service changed.

Change-Id: I9d253d7519b1774985d165a080047fdbecd321b4

This change enables the use of Docker healthchecks for aodh services.
Implements: blueprint container-health-check

Change-Id: Ic477ac77f7ea5c50de473382fb1ec63d78043267

This change enables the use of Docker healthchecks for gnocchi services.
Implements: blueprint container-health-check

Change-Id: Ib1eb766d061c376c0bdd693dd6ea1e5b3e3fc02a

This change enables the use of Docker healthchecks for ironic services.
Implements: blueprint container-health-check

Change-Id: If0a11db5470899c3a0e69ca94fdd0903daadcf8b

This change enables the use of Docker healthchecks for designate services.
Implements: blueprint container-health-check

Change-Id: Ide66a914b790ad9c106ba932a923654a960f7abf

Min version stays as 2.9

Change-Id: I7ec8c5eb36757248c9aa016dc7d4e495ec5bb635

Change-Id: Ief84e093829677c97c8df9a08aefca43b1e51aac

The merge_configs action plugin is updated with an option to control
whether whitespace should be used around equal signs. The default
remains to use whitespace: only zookeeper.cfg doesn't use them.

This is to avoid issues with the zkCleanup.sh script which expects no
whitespace. The ZooKeeper documentation also uses no whitespace in
configuration file examples.

Change-Id: Ia082a1c002cc4e8b04f7696fdee827b747c6d13f
Closes-Bug: #1917490

In services which use the Apache HTTP server to service HTTP requests,
there exists a TimeOut directive [1] which defaults to 60 seconds. APIs
which come under heavy load, such as Cinder, can sometimes exceed this
which results in a HTTP 504 Gateway timeout, or similar. However, the
request can still be serviced without error. For example, if Nova calls
the Cinder API to detach a volume, and this operation takes longer
than the shortest of the two timeouts, Nova will emit a stack trace
with a 504 Gateway timeout. At some time later, the request to detach
the volume will succeed. The Nova and Cinder DBs then become
out-of-sync with each other, and frequently DB surgery is required.

Although strictly this category of bugs should be fixed in OpenStack
services, it is not realistic to expect this to happen in the short
term. Therefore, this change makes it easier to set the Apache HTTP
timeout via a new variable.

An example of a related bug is here:

https://bugs.launchpad.net/nova/+bug/1888665

Whilst this timeout can currently be set by overriding the WSGI
config for individual services, this change makes it much easier.

Change-Id: Ie452516655cbd40d63bdad3635fd66693e40ce34
Closes-Bug: #1917648

This change allows a user to forward control plane logs
directly to Elasticsearch from Fluentd, rather than via
the Monasca Log API when Monasca is enabled. The Monasca
Log API can continue to handle tenant logs.

For many use cases this is simpler, reduces resource
consumption and helps to decouple control plane logging
services from tenant logging services.

It may not always be desired, so is optional and off by
default.

Change-Id: I195e8e4b73ca8f573737355908eb30a3ef13b0d6

The Monasca alerting pipeline provides multi-tenancy alerts and
notifications. It runs as an Apache Storm topology and generally
places a significant memory and CPU burden on monitoring hosts,
particularly when there are lot of metrics. This is fine if the
alerting service is in use, but sometimes it is not. For example
you may use Prometheus for monitoring the control plane, and
wish to offer tenants a monitoring service via Monasca without
alerting and notification functionality. In this case it makes
sense to disable this part of the Monasca pipeline and this patch
adds support for that.

If the service is ever re-enabled, all alerts and notifications
should spawn back automatically since they are persisted in the
central mysql database cluster.

Change-Id: I84aa04125c621712f805f41c8efbc92c8e156db9

The Log Metrics service is an admin only service. We now have
support in Fluentd via the Prometheus plugin to create metrics
from logs. These metrics can be scraped into Monasca or Prometheus.
It therefore makes sense to deprecate this service, starting by
disabling it by default, and then removing it in the Xena release.
This should improve the stability of the Monasca metrics pipeline
by ensuring that all metrics pass via the Monasca API for
validation, and ensure that metrics generated from logs are
available to both Prometheus and Monasca users by default.

Change-Id: I704feb4434c1eece3eb00c19dc5f934fd4bc27b4

Historically Monasca Log Transformer has been for log
standardisation and processing. For example, logs from different
sources may use slightly different error levels such as WARN, 5,
or WARNING. Monasca Log Transformer is a place where these could
be 'squashed' into a single error level to simplify log searches
based on labels such as these.

However, in Kolla Ansible, we do this processing in Fluentd so
that the simpler Fluentd -> Elastic -> Kibana pipeline also
benefits. This helps to avoid spreading out log parsing
configuration over many services, with the Fluentd Monasca output
plugin being yet another potential place for processing (which
should be avoided). It therefore makes sense to remove this
service entirely, and squash any existing configuration which
can't be moved to Fluentd into the Log Perister service. I.e.
by removing this pipeline, we don't loose any functionality,
we encourage log processing to take place in Fluentd, or at least
outside of Monasca, and we make significant gains in efficiency
by removing a topic from Kafka which contains a copy of all logs
in transit.

Finally, users forwarding logs from outside the control plane,
eg. from tenant instances, should be encouraged to process the
logs at the point of sending using whichever framework they are
forwarding them with. This makes sense, because all Logstash
configuration in Monasca is only accessible by control plane
admins. A user can't typically do any processing inside Monasca,
with or without this change.

Change-Id: I65c76d0d1cd488725e4233b7e75a11d03866095c

This change enables the use of Docker healthchecks for octavia services.
Implements: blueprint container-health-check

Change-Id: I2ec11544b0e9c66a1821bfe0f9a40a9e9d88033b

- bind health manager port to ovs
- create a octavia-interface.service (used for creating health manager
  interface after reboot)
- used for ci, test or poc

Implements: blueprint implement-automatic-deploy-of-octavia

Change-Id: I8ac30dea6c8402d97189c6b05032c608936b0ff2
Co-Authored-By: wu.chunyang <wuchunyang@yovole.com>

Deprecates support for Prometheus v1.x.
In Xena support for it will be removed from Kolla Ansible.

Change-Id: I027b19621196c698e09f79af294ba1b5dbfc0516

Change-Id: Ib6719a033b37be3e248b682795b7243c60b22b84

This change enables the use of Docker healthchecks for trove services.
Implements: blueprint container-health-check

Change-Id: I55badd93f92f82e020ef80b06c788600e597d068

Currently kolla-ansible uses the same CIDR in init-run-once script
and for octavia_amp_network_cidr.

Change-Id: I5ab24fbf9be4acbd691f13d33908aa44d2b4d496

The Cinder API log is currently written to a file called
cinder-wsgi.log, and the WSGI logs to cinder-api.log. Fluentd
then tries to parse the WSGI log as an OpenStack log which
results in 'got incomplete line' errors and prevents proper
ingestion of these logs.

Co-Authored-By: yaoning <yaoning@unitedstack.com>
Closes-Bug: 1916752
Change-Id: I3296dcc4780160cbf88bd18285571276f58bb249

This commit adds possibility to deploy Neutron's DHCP agents in OVN
networking scenario.

Co-Authored-By: Michał Nasiadka <mnasiadka@gmail.com>

Change-Id: I073d04319b510182f5c1478e728c0c5bcc8799f1

This change enables the use of Docker healthchecks for magnum
services.
Implements: blueprint container-health-check

Change-Id: I14d862aa599915c781d02b71a0e57d2124de9abc

it was confused to customize opts in trove-conductor.conf
or trove-taskmanager.conf now.
if we want to customize a opts,The operator needs
to know which service is using the configuration opts.
actually trove uses trove.conf is enough for all services
this change combines  all trove config files.

Change-Id: I5a630109e3c4b59bff216146a3ed64c6d47e247f

It currently runs on hosts in ovn group, and in case that controllers are not
network gateways - it fails on missing openvswitch.

Change-Id: Ibbf683872337402b4e2a38323bb6a3f35ee4bed4

In I173669bdf92b1f2ea98907ba16808ca3c914944c, eswitchd.conf.j2 template
file missed a .j2 at the end. This PS rectifies it.

Change-Id: I251febe3fd192372177116569f41ccb9aa225302

This pull request adds support for the OpenID Connect authentication
flow in Keystone and enables both ID and access token authentication
flows. The ID token configuration is designed to allow users to
authenticate via Horizon using an identity federation; whereas the
Access token is used to allow users to authenticate in the OpenStack CLI
using a federated user.

Without this PR, if one wants to configure OpenStack to use identity
federation, he/she needs to do a lot of configurations in the keystone,
Horizon, and register quite a good number of different parameters using
the CLI such as mappings, identity providers, federated protocols, and
so on. Therefore, with this PR, we propose a method for operators to
introduce/present the IdP's metadata to Kolla-ansible, and based on the
presented metadata, Kolla-ansible takes care of all of the
configurations to prepare OpenStack to work in a federated environment.

Implements: blueprint add-openid-support
Co-Authored-By: Jason Anderson <jasonanderson@uchicago.edu>
Change-Id: I0203a3470d7f8f2a54d5e126d947f540d93b8210

- Increment retries: waiting 20 seconds (i.e., 10 retries) seem to
  be not enough for monasca-grafana to start on the first node.
  Increasing to 80 seconds (i.e., 40 retries) fixes the issue.

- Prevent the check from running when kolla_action=config. In that
  case, the command would never succeed as the service is not
  deployed yet (similarly to
  https://review.opendev.org/c/openstack/kolla-ansible/+/771237).

Closes-Bug: #1915060
Related-Bug: #1821285
Change-Id: I7b42c51a66caed0eccf118615d841dca97a7af9d

and prometheus collector backend support.

* Fix various remaining typos.
* Fix trailing character on reno.
* Enable Elasticsearch when selected as cloudkitty backend.
* Add a check for ES index creation when ES required.
* Add a release note
* Fix release note line length issue.

Change-Id: I18f3d8f2e10a2996b2ebf92733a1770bef548bda
Closes-bug: #1895945

If the Octavia/Amphora management network is created by Kolla, support
setting the IP address family and IPv6 address/RA mode.

Closes-Bug: 1913409

Change-Id: I9f2ef2196654c91596cb5c4b3c157bcee267226a

This change enables the use of Docker healthchecks for manila services.
Implements: blueprint container-health-check

Change-Id: I3a2239764b7e3d6db51e535404388a512aba7629

Need to consider Negative seqno to compare in some cases,
but the task does not support to do that, we need to make it work.

1.we use mariabackup to restore datas on control1, delete the
mariadb data on control2 and control3, and then use cluster recovery,
 as a result that the seqno of the other two nodes will be '-1'.

2. add one more control node into our existing mariadb cluster,
and then use cluster recovery, the seqno of the new node will be '-1'.

Change-Id: Ic1ac8656f28c3835e091637014f075ac5479d390