Kolla Ansible now claims [1] to support executing as a user other than
root.  We should ensure that this is tested in CI.

This change removes the 'become' from hosts in the inventory, and sets
the remote user to 'kolla', as configured via the bootstrap-servers
command. The bootstrap-servers command and other ansible commands
executed before it still need to execute as the zuul user and not as
kolla, since kolla does not exist yet.

The autogenerated SSH private key in passwords.yml is now added to the
zuul user's SSH config, such that it can SSH as the kolla user, which
has authorised this key.

[1]
https://blueprints.launchpad.net/kolla-ansible/+spec/ansible-specific-task-become

Change-Id: I8f3587e2908bc5b8889cd6fbc01981a6186d33e6

Various ceph-related tasks were missing a 'become' that would allow them
to work as a non-root user. This seems to only cause a problem after an
initial deployment, perhaps due to the recursive ownership & permissions
changes at the end of the ceph.yml and external_ceph.yml files.

This change adds the necessary becomes.

Change-Id: I887c7b3bdef49db1dd1bf9e5bdbf5dc47b7f41af
Closes-Bug: #1795125

This is required to support execution as a non-root user.

Change-Id: I017b44352a33884102fefbacdde0fddc7f0282e3
Closes-Bug: #1795125

Following by https://review.openstack.org/#/c/605097/
These were used by now-dead tooling. We can remove them.

Change-Id: I0953751044f038a3fdd1acd49b3d2b053ac4bec8

Having all services in one giant haproxy file makes altering
configuration for a service both painful and dangerous. Each service
should be configured with a simple set of variables and rendered with a
single unified template.

Available are two new templates:

* haproxy_single_service_listen.cfg.j2: close to the original style, but
only one service per file
* haproxy_single_service_split.cfg.j2: using the newer haproxy syntax
for separated frontend and backend

For now the default will be the single listen block, for ease of
transition.

Change-Id: I6e237438fbc0aa3c89a3c8bd706a53b74e71904b

The log metrics service generates metrics from log messages
which allows further analysis and alerting to be performed
on them. Basic configuration is provided so that metrics
are generated for high level warning logs such as error, or
warning.

Change-Id: I45cc17817c716296451f620f304c0b1108162a56
Partially-Implements: blueprint monasca-roles

Change-Id: Id8948fcf2d165f8285c7562e7aebd4145c4ff0db
Partially-Implements: blueprint monasca-roles

Set sensible defaults for replica counts and minimum insync replicas
as a function of the number of nodes in the Kafka cluster.

Partially-Implements: blueprint monasca-roles
Change-Id: Icf1dddb7dd6a64f4e5efb7dffa5ffdf0880f891f

This option doesn't actually do anything and a bug to remove
it from the Monasca API config file has been raised.

Partially-Implements: blueprint monasca-roles
Change-Id: I7ec1786b5828ab0135ca86ec040f83a6f4c78d9f

Change-Id: I0444b23aee900d028c879ec64d153d59a18ff504

 - Uses swift if swift is enabled.
 - Uses ceph if ceph is enabled.
 - Defaults to file if swift and ceph are enabled.
   Explicitly set to swift or ceph when both are enabled.
 - Include swift client detail in storage section of gnocchi conf

Change-Id: I78df9a2fbe546038e1d6df350d8db0fd9b6f6d49

Depends-On: I75e00312b36e1678b90a42cf58d24652323eff27
Change-Id: Ia716fabffca41eff816e59bbf9f4cab79ee8b72f

Fix a typo in the policy task name

Change-Id: I43b9c1ea1e3ff4bef1713c889e2cb885207abb0e

Add a possibility to mount sources as volumes to containers,
in "more than documentation" way. That will let us to use kolla
as a replacement for devstack.

Partially implements: blueprint mount-sources
Co-Authored-By: wu.chunyang <wu.chunyang@99cloud.net>

Change-Id: Ia3112a0d297ac777e1f25d3ddecced7746ca6418

Change-Id: Ia1fa141acd7233f0c9dd30dd3d13e31cf1a2fb8e

Alembic uses the monasca-agent config file for the DB
credentials. These are therefore no longer required.

Partially-Implements: blueprint monasca-roles
Change-Id: Id076e7a0b838888314159dd9e76697f89adecb5e

If there is a change to kolla then images are built, which can push the
job over the existing 1.5 hour timeout. These jobs are also used in the
kolla CI.

Change-Id: I88a28745cf834376163ced36984c317fce831346

This patchset apply Nova rolling upgrade logic [1]

[1] https://docs.openstack.org/nova/latest/user/upgrade.html



Implements: blueprint apply-service-upgrade-procedure

Co-Authored-By: Ha Manh Dong <donghm@vn.fujitsu.com>
Depends-On: https://review.openstack.org/#/c/558765/
Change-Id: I20531a25dc7f5b05dc70ba771cf4c4222ade33e3

For now, we use api interface/network for Octavia.

This change will make more flexible for Octavia deployment
with Kolla when we want to use another network for managing
amphora instances (config, health check, clean up)

Change-Id: Ief12f1f8b6c7d3974932e6320af95bb58d46bdb9
Co-Authored-By: Duc Nguyen Cong <ducnc7@viettel.com.vn>
Closes-Bug: #1791207