Remove rally role as planned

Change-Id: Ic898efe42b21b01c45d4621af2cf90ecd7afc398

They are handled by Docker since at least 18.09 (tested).
Backport to Wallaby at most to not introduce needless restarts in
already stable branches.

Depends-On: https://review.opendev.org/c/openstack/kolla-ansible/+/792583
Change-Id: Ia95355c529f1b0222dc1de06632984b6d130b9ec

the project is deprecated and in the process of being removed
from OpenStack upstream.

Change-Id: I9d5ebed293a5fb25f4cd7daa473df152440e8b50

With the new default since Wallaby, starting Docker makes it
enable forwarding and not filter it at all.
This may pose a security risk and should be mitigated.

Closes-Bug: #1931615
Change-Id: I5129136c066489fdfaa4d93741c22e5010b7e89d

The host list order seen during Ansible handlers may differ to the usual
play host list order, due to race conditions in notifying handlers. This
means that restart_services.yml for RabbitMQ may be included in a
different order than the rabbitmq group, resulting in a node other than
the 'first' being restarted first. This can cause some nodes to fail to
join the cluster. The include_tasks loop was introduced in [1].

This change fixes the issue by splitting the handler into two tasks, and
restarting the first node before all others.

[1] https://review.opendev.org/c/openstack/kolla-ansible/+/763137

Change-Id: I1823301d5889589bfd48326ed7de03c6061ea5ba
Closes-Bug: #1930293

Since I0474324b60a5f792ef5210ab336639edf7a8cd9e swift role uses the new
service-cert-copy role introduced in the
I6351147ddaff8b2ae629179a9bc3bae2ebac9519 but the swift role itself
doesn't contain the handler used in the service-cert-copy. Right now,
restarting the swift container isn't necessary, but the handler should
exist. Also we should fix the name of the service used.

Closes-Bug: #1931097
Change-Id: I2d0615ce6914e1f875a2647c8a95b86dd17eeb22
Signed-off-by: Maksim Malchuk <maksim.malchuk@gmail.com>

On machines with many cores, we were seeing excessive CPU load on systems
that were not very busy. With the following Erlang VM argument we saw
RabbitMQ CPU usage drop from about 150% to around 20%, on a system with
40 hyperthreads.

    +S 2:2

By default RabbitMQ starts N schedulers where N is the number of CPU
cores, including hyper-threaded cores. This is fine when you assume all
your CPUs are dedicated to RabbitMQ. Its not a good idea in a typical
Kolla Ansible setup. Here we go for two scheduler threads.
More details can be found here:
https://www.rabbitmq.com/runtime.html#scheduling
and here:
https://erlang.org/doc/man/erl.html#emulator-flags

    +sbwt none

This stops busy waiting of the scheduler, for more details see:
https://www.rabbitmq.com/runtime.html#busy-waiting
Newer versions of rabbit may need additional flags:
"+sbwt none +sbwtdcpu none +sbwtdio none"
But this patch should be back portable to older versions of RabbitMQ
used in Train and Stein.

Note that information on this tuning was found by looking at data from:
rabbitmq-diagnostics runtime_thread_stats
More details on that can be found here:
https://www.rabbitmq.com/runtime.html#thread-stats

Related-Bug: #1846467

Change-Id: Iced014acee7e590c10848e73feca166f48b622dc

The chrony container is deprecated in Wallaby, and disabled by default.
This change allows to remove the container if chrony is disabled.

Change-Id: I1c4436072c2d47a95625e64b731edb473384b395

Makes nova-libvirt container always run in 'host' CgroupnsMode
to ensure it works.

Change-Id: I75105baf434977c68bc5c8ca1f5213e602c52c8c

This is required to support Debian Bullseye (11) - need to set
nova-libvirt to use 'host' CgroupnsMode.

Change-Id: I40213d4092fa325bcf37bb1fb4437ab125fe328b

And python-docker version.
Make them less scary.

Change-Id: I134e8aa8ed5eae479e5af743464dc2a0e40a1353

The mariadb image was removed in Wallaby, leading to database backup
failures.

Change-Id: I90986e7521779997df2782767bb95efcbd8ef232
Closes-Bug: #1928129

This configuration option was only used by neutron-lbaas, which is now
retired. It should have been added to neutron_lbaas.conf.j2 instead.

Change-Id: Iba591473abf4304413eca0d84e0b2be197c527fc

Change-Id: If2fdab2ae0f981d9fcbb0fea7a92fcde325804f8

Docker 5.0.0 [1] dropped requirement for six, but still imports it.

[1]: https://github.com/docker/docker-py/issues/2807

Closes-Bug: #1928915
Change-Id: I726541f4b3fdc357387a44c6a2153593a10bf282

docker-ce on Debian/Ubuntu gets started just after installation, before
baremetal role configures daemon.json - which results in iptables rules
being implemented - but not removed on docker engine restart.

Closes-Bug: #1923203

Change-Id: Ib1faa092e0b8f0668d1752490a34d0c2165d58d2

Change-Id: I30988176c8d5a59cf61527af1a43c5d33ba6268d

Reference:

https://github.com/prometheus/alertmanager#turn-off-high-availability

Closes-Bug: #1926463
Change-Id: I60e1dedeac25fa8fe9538a3a8e582bd8cc9324d7

* Enables the Neutron packet logging framework for OVS
(https://docs.openstack.org/neutron/latest/admin/config-logging.html).
* Adds a toggle variable "enable_neutron_packet_logging"

Change-Id: Ica3594cdac634b496949a06ed813dccd18090af4
Implements: blueprint neutron-log-service-plugin

This is a follow up on the change with the following ID:

I337f42e174393f68b43e876ef075a74c887a5314

TrivialFix

Change-Id: Ibb67811d7b086ef9ef4c695ae589171af0c4d657

we don't need this task anymore.

Change-Id: I1ba60fa51ecc86c74d05898b897d7b84c70707ef

This task is writing private key from passwords to
/etc/kolla/octavia-worker/{{ octavia_amp_ssh_key_name }} even
if user disabled octavia auto configure.

This patch is adding conditional for this task and skipping
it if octavia_auto_configure: "no".

Closes-Bug: #1927727

Change-Id: Ib993b387d681921d804f654bea780a1481b2b0d0

Change-Id: Ib85cc2cb10e3c97de9f7d608e75694a0fc2714c2

In order for DVR to work on VLAN tenant networks we need to configure
external_ids:ovn-chassis-mac-mappings with per node generated MAC [1]
on computes [1].

[1]: https://github.com/ovn-org/ovn/commit/1fed74cfc1a1e3b29cf86eab2e96048813019b57



Co-Authored-By: Bartosz Bezak <bartosz@stackhpc.com>

Depends-On: https://review.opendev.org/c/openstack/neutron/+/782250
Change-Id: I3a3ccde5b9ef2afb4c3e9206f13827687880cb57

Co-Authored-By: Bartosz Bezak <bartosz@stackhpc.com>

Change-Id: I4fc2cb451589dfec82c343868667020f8dcee901

Per [1].

[1] http://eavesdrop.openstack.org/meetings/kolla/2021/kolla.2021-04-28-15.00.html

Change-Id: Ie109d15db1e26e20b78efdb4ab0653d24054820f

As agreed during IRC meeting. [1]

[1] http://eavesdrop.openstack.org/meetings/kolla/2021/kolla.2021-04-07-15.00.html

Change-Id: Ibffa019e2106784e97f5c482106bb5082f788752

In the Xena cycle it was decided to remove the Monasca
Grafana fork due to lack of maintenance. This commit removes
the service and provides a limited workaround using the
Monasca Grafana datasource with vanilla Grafana.

Depends-On: I9db7ec2df050fa20317d84f6cea40d1f5fd42e60
Change-Id: I4917ece1951084f6665722ba9a91d47764d3709a

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

Followup on I91e5c1840ace8f567daf462c4eb3ec1f0c503823

When+run_once do not play nicely. [1]
The general workaround is to use include_tasks. [2]
However, it is very unlikely user wishes to run this role
without having any pacemaker nodes so the simplification that we
use throughout the Kolla Ansible code should be enough.

[1] https://github.com/ansible/ansible/issues/11496
[2] https://github.com/ansible/ansible/issues/11496#issuecomment-412936547

Change-Id: Ifaf64e3d9d89b2ec36a883fb7458556745b64802

If docker_configure_for_zun is set to true, then Zun-specific
configuration for Docker is applied to all nodes. It should only be
applied based on the relevant inventory groups. In some cases this can
cause Docker to fail to start. See
https://storyboard.openstack.org/#!/story/2008544

 for details.

This change applies the configuration based on the zun-compute and
zun-cni-daemon groups. It also modifies the expression to not assume
that these groups exist in the inventory.

Change-Id: I0141abf0dd83e3a567ea6dcca945f86db129becf
Closes-Bug: #1914378
Story: 2008544
Task: 41645
Co-Authored-By: Buddhika Sanjeewa <bsanjeewa@kln.ac.lk>

Change-Id: I14376dac46809f8bb466ec41f279be8d323d459d

 - Replace hardcoded haproxy monitor user with variable.
 - Rename mariadb_backup variable to mariadb_backup_possible.
 - Drop creation of monitor user in handlers as this is
   now handled in register.yml for good reason.

Change-Id: I255a79d36ae18ca42d0befd00b235ca509197db3

Change-Id: Id16ec7d7b57630ae20430675c4a196e63ca8d4a5

Change-Id: I1010ee42aaf1c650d9e3b5332ebf828646a6badf

Change-Id: I3f43df7766c57622ab8d01a759fbeeef0a0c2b93
Implements: blueprint masakari-hostmonitor
Co-Authored-By: Radosław Piliszek <radoslaw.piliszek@gmail.com>

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>

* 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

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