Change-Id: I81a4f8f8b8faa7559740531bb16d8aec7fc23f9b

Change-Id: I77791d504327ace880d0cc2438af2f8ced66d4eb

trivial fix
see: https://review.opendev.org/c/openstack/kolla-ansible/+/763191

Change-Id: I7f5a5ba5e9a6b3866fc4d2c72b7b4884c85020bd

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

Change-Id: If42b7324b58851a4f0beb3a80c70ca2c9dd729af

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

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

If kolla-ansible is installed via pip install --user, currently the
kolla-ansible script is unable to locate the installed playbooks.
This leads to a failure when running commands.

This change fixes the issue by checking for the user's .local directory
as a possible installation path.

This fixes some of the scenario tests which were failing after switching
to a user installation in Ifaf1948ed5d42eebaa62d7bad375bbfc12b134d5.
Most tests did not fail since the kolla-ansible script in the source
checkout was used.

Closes-Bug: #1915527

Change-Id: I5b47a146627d06bb3fe4a747c5f20290c726b0f9

Installing ceph-ansible in the virtualenv on CentOS 8 fails with:

    ModuleNotFoundError: No module named 'setuptools_rust'

This error appeared following the release of cryptography 3.4, which now
includes Rust code. It can be installed without Rust using a Python
wheel, but only with more recent pip than version 9.0.3 available as RPM
on CentOS 8. The cryptography bug report [1] recommends pip>=19.1.1.

This change upgrades pip in the virtualenv before installing
ceph-ansible.

[1] https://github.com/pyca/cryptography/issues/5753

Change-Id: I47473de6f71c422db2238d653c2d8f379c55e79b

- 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

Installing kolla-ansible system-wide on CentOS 8 fails with:

    ModuleNotFoundError: No module named 'setuptools_rust'

This error appeared following the release of cryptography 3.4, which now
includes Rust code. It can be installed without Rust using a Python
wheel, but only with more recent pip than version 9.0.3 available as RPM
on CentOS 8. The cryptography bug report [1] recommends pip>=19.1.1.

This change switches to using pip --user when installing kolla-ansible.

Also fixes an issue with ansible-lint which was failing on
etc/kolla/globals.yml due to a missing space before comments.

[1] https://github.com/pyca/cryptography/issues/5753

Change-Id: Ifaf1948ed5d42eebaa62d7bad375bbfc12b134d5
Closes-Bug: #1915141

One of the renos was causing issues due to a duplicated id.
This change makes tox doc8 env lint renos and fixes
the offending reno.

Change-Id: Id3ae6e144b4261c97726cdec172ea9bef093de9e

Stolen from Kayobe.

Change-Id: I42a2ef84e5fe570e8001908614337e64d035ec99

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

There are inconsitencies across the documentation and the source code files
when it comes to project's name (Kolla Ansible vs. Kolla-Ansible). This
commit aims at unifying it so that the naming becomes consistent everywhere.

Change-Id: I903b2e08f5458b1a1abc4af3abefe20b66c23a54

There are a few issues fixed here:

- The Barbican API service doesn't set a log file, so all the Barbican API
  service logs go to loadwsgi.py.log by default.
- The logs in loadwsgi.py.log are not ingested properly by Fluentd.
- uWSGI logs go to barbican-api.log. This would normally be used as the log
  file for the Barbican API service logs.

This patch makes the following changes to address the above issues:

- All uWSGI logs (from the Emperor and Vassals) go to barbican_api_uwsgi_access.log
  Although these logs aren't strictly all access logs, this follows the existing
  pattern for WSGI logs.
- The Barbican API service logs are written to barbican-api.log instead of
  loadwsgi.py.log. This follows the pattern used by other OpenStack services.
- Fluentd is configured to parse the Barbican API service logs as it would with
  other OpenStack Python services.

Change-Id: I6d03fa8c81c52b6f061514a836bbd15bb6639aaf
Closes-Bug: #1891343