Change-Id: Ib5490d504a5b7c9a37dda7babf1257aa661c11de

This reverts commit 8ce5ffd0.

Change-Id: I81ce7c007ff267ebbbb721bcdb7eebc0dd575bf8

Change-Id: Ia7041be384ac07d0a790c2c5c68b1b31ff0e567a

During an upgrade, nova pins the version of RPC calls to the minimum
seen across all services. This ensures that old services do not receive
data they cannot handle. After the upgrade is complete, all nova
services are supposed to be reloaded via SIGHUP to cause them to check
again the RPC versions of services and use the new latest version which
should now be supported by all running services.

Due to a bug [1] in oslo.service, sending services SIGHUP is currently
broken. We replaced the HUP with a restart for the nova_compute
container for bug 1821362, but not other nova services. It seems we need
to restart all nova services to allow the RPC version pin to be removed.

Testing in a Queens to Rocky upgrade, we find the following in the logs:

Automatically selected compute RPC version 5.0 from minimum service
version 30

However, the service version in Rocky is 35.

There is a second issue in that it takes some time for the upgraded
services to update the nova services database table with their new
version. We need to wait until all nova-compute services have done this
before the restart is performed, otherwise the RPC version cap will
remain in place. There is currently no interface in nova available for
checking these versions [2], so as a workaround we use a configurable
delay with a default duration of 30 seconds. Testing showed it takes
about 10 seconds for the version to be updated, so this gives us some
headroom.

This change restarts all nova services after an upgrade, after a 30
second delay.

[1] https://bugs.launchpad.net/oslo.service/+bug/1715374
[2] https://bugs.launchpad.net/nova/+bug/1833542

Change-Id: Ia6fc9011ee6f5461f40a1307b72709d769814a79
Closes-Bug: #1833069
Related-Bug: #1833542

They are used only to obtain keys for the next task.

Change-Id: I2fac22af4710b70e4df8e3a272bcfb6cc8b8532e
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>

Merge "link kolla_logs volume to docker_runtime_directory if docker_runtime_directory variable exists"

The Hitachi NAS Platform iSCSI driver was marked as not supported by
Cinder in the Ocata realease[1].

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

Change-Id: I1a25789374fddaefc57bc59badec06f91ee6a52a
Closes-Bug: #1832821

In some cases, we can mount extra volumes for gnocchi to facilitate
integration.

Change-Id: Ife475ca7d0555562f6e3ef0867835d69d288c8c4
Signed-off-by: ZijianGuo <guozijn@gmail.com>

"Check if policies shall be overwritten" already exists in its
newer form. The removed one had no effect on play.

Change-Id: I48ed6c1c71c4162a3ab28ab2b51dc1e02932dfef
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>

Actually, 'mongodb.conf' is a yaml format configuration file. Do not use
merge_configs to merge it.

Change-Id: Id3c006df00c1e2d66472c2195781e01c640cab22
Signed-off-by: ZijianGuo <guozijn@gmail.com>

The TSI is recommended for all users. Some of the key benefits are
a reduction in memory requirements and an increase in the maximum
number of time series. For more information see this link:

https://docs.influxdata.com/influxdb/v1.7/concepts/tsi-details/

Change-Id: I4b29eb5a4ae82f6c39059d0b6de41debdfd75508

Since this review[1], Qinling supports WSGI execution.

From a production perspective, Qinling should be deployed
using Apache and mod_wsgi.

"api_worker" option is not needed anymore because processes will
be handle by Apache mod_wsgi.

Qinling Docker image review[2] has ben created.

[1] https://review.opendev.org/661851
[2] https://review.opendev.org/666647

Change-Id: I9aaee4c2932f1e4ea9fe780a64e96a28fa6bccfb
Story: 2005920
Task: 34181

Docker registry being insecure is handled by docker_registry_insecure
which is set to true by default when docker_registry is set.
The removed code had no effect because docker_registry is not changed
anyway for base (pre-upgrade) install.

This change makes config more readable and also prevents a potential
conflict with the zun profile if ever used in upgrade mode.

Change-Id: I9b5ae8c5b534fa6cce9dbaca8af191e2ca79d19f
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>

Change-Id: I99d4ea6ca615bdde83cd55d91672733d9b95372a
Signed-off-by: Radosław Piliszek <radoslaw.piliszek@gmail.com>

This commit should help guide people migrating to Kolla Monasca
through the murky depths of the migration process. Since Kolla
did not support Monasca in Queens, some of these steps which
could be automated are not.

Change-Id: I79051cca27178c3cf1671f5c603e38baf929c55c

The "environment" variable set in config.yml and handlers/main.yml
has been removed to fix de deployment and the reconfigure.

Change-Id: I912cadb5113d5572235731863825588b2eb12759