This change enables the use of Docker healthchecks for rabbitmq services.

Implements: blueprint container-health-check
Depends-On: https://review.opendev.org/c/openstack/kolla/+/784562

Change-Id: I23a2c2efab858b9ed39c6ce0ec4a82df10e7f93d

Change-Id: I1010ee42aaf1c650d9e3b5332ebf828646a6badf

It will allow us to fail fast when pulling the image
is a problem - instead of failing in the middle of
deployment.

Change-Id: I017cddcfbbc5449e63d807385216b94e74503c9b

Adds HAcluster Ansible role. This role contains High Availability
clustering solution composed of Corosync, Pacemaker and Pacemaker Remote.

HAcluster is added as a helper role for Masakari which requires it for
its host monitoring, allowing to provide HA to instances on a failed
compute host.

Kolla hacluster images merged in [1].

[1] https://review.opendev.org/#/c/668765/



Change-Id: I91e5c1840ace8f567daf462c4eb3ec1f0c503823
Implements: blueprint ansible-pacemaker-support
Co-Authored-By: Radosław Piliszek <radoslaw.piliszek@gmail.com>
Co-Authored-By: Mark Goddard <mark@stackhpc.com>

Kolla-ansible is currently installing mariadb
cluster on hosts defined in group['mariadb']
and render haproxy configuration for this hosts.

This is not enough if user want to have several
service databases in several mariadb clusters (shards).

Spread service databases to multiple clusters (shards)
is usefull especially for databases with high load
(neutron,nova).

How it works ?

It works exactly same as now, but group reference 'mariadb'
is now used as group where all mariadb clusters (shards)
are located, and mariadb clusters are installed to
dynamic groups created by group_by and host variable
'mariadb_shard_id'.

It also adding special user 'shard_X' which will be used
for creating users and databases, but only if haproxy
is not used as load-balance solution.

This patch will not affect user which has all databases
on same db cluster on hosts in group 'mariadb', host
variable 'mariadb_shard_id' is set to 0 if not defined.

Mariadb's task in loadbalancer.yml (haproxy) is configuring
mariadb default shard hosts as haproxy backends. If mariadb
role is used to install several clusters (shards), only
default one is loadbalanced via haproxy.

Mariadb's backup is working only for default shard (cluster)
when using haproxy as mariadb loadbalancer, if proxysql
is used, all shards are backuped.

After this patch will be merged, there will be way for proxysql
patches which will implement L7 SQL balancing based on
users and schemas.

Example of inventory:

[mariadb]
server1
server2
server3 mariadb_shard_id=1
server4 mariadb_shard_id=1
server5 mariadb_shard_id=2
server6 mariadb_shard_id=3

Extra:
wait_for_loadbalancer is removed instead of modified as its role
is served by check already. The relevant refactor is applied as
well.

Change-Id: I933067f22ecabc03247ea42baf04f19100dffd08
Co-Authored-By: Radosław Piliszek <radoslaw.piliszek@gmail.com>

Minor corrections to doc and release note.

Change-Id: I8a90cbac0b9a1eaa5f6c02271515f2357547f908

* Don't generate masakari.conf for instance monitor
* Don't generate masakari-monitors.conf for API or engine
* Use a consistent name for dimensions -
  masakari_instancemonitor_dimensions
* Fix source code paths in dev mode

Change-Id: I551f93c9bf1ad6712b53c316074ae1df84e4352b

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

Change-Id: I413f484d60d7cdfa03f3f8d779f07462be15d2dd

Often cephadm jobs fail with:
Mar 30 13:01:21 primary bash[75459]: debug 2021-03-30T13:01:21.844+0000 7fa30431f700 -1 error: monitor data filesystem reached concerning levels of available storage space (available: 4% 1.8 GiB)

Let's check if 5G OSD helps and also print df -h output for reference

Change-Id: I6960fd0f378aea5a14a73d9228edf86fb86cac6c

We can't check this with timedatectl as it is not aware
of any "non-native" NTP daemon.

This could be a warning-level message but we don't have
such messages from the prechecks.

Closes-Bug: #1922721
Change-Id: I6db37576118cf5cff4ba7a63e179f0ab37467d22

Per [1].

[1] http://lists.openstack.org/pipermail/openstack-discuss/2021-February/020707.html

Change-Id: Id6f3cd158bf5d01750971249b11364b6a8631789
Closes-Bug: #1885689

Based on the discussions from the past 3 Kolla meetings [1][2][3],
we established that, to avoid the DockerHub pull limit issues
in our CI, we will try using quay.io.

The images have already been published via Kolla CI
for master/Wallaby [4] and Victoria [5].

This change applies only to CI.
The user-facing move is yet to be discussed.

[1] http://eavesdrop.openstack.org/meetings/kolla/2021/kolla.2021-03-17-15.00.log.html#l-102
[2] http://eavesdrop.openstack.org/meetings/kolla/2021/kolla.2021-03-24-15.00.log.html#l-137
[3] http://eavesdrop.openstack.org/meetings/kolla/2021/kolla.2021-03-31-15.01.log.html#l-50
[4] https://review.opendev.org/c/openstack/kolla/+/781130
[5] https://review.opendev.org/c/openstack/kolla/+/781899

Change-Id: I22e11a994801447526ac26fc2815a1679876225e

After WSGI implementation the permissions were not fixed.

Depends-On: https://review.opendev.org/c/openstack/kolla/+/783845

Change-Id: I908efe29dcd16c10b0bc88582d8dfb23ba573a35

Change-Id: I947c2940518c0f4872acaa977edeaca370dc9a96

host -> host_ip[0]
Remove deprecated configuration notification_topics.

WARNING oslo_config.cfg [-] Deprecated: Option "notification_topics"
from group "DEFAULT" is deprecated. Use option "topics" from
group "oslo_messaging_notifications".

[0]https://docs.openstack.org/cyborg/latest/configuration/sample-config.html

Change-Id: Ia5d53fb60d34c1509c6cdb905cbd0a93dd1c8b3d