Currently, the serial consoles as accessed through Horizon,
timeout after the haproxy_client_timeout (default: 1m) of
inactivity. This change allows you to set a larger timeout.

Change-Id: I2a9923cb69d5db976395146685aded83922c4120
Closes-Bug: #1800643

Change-Id: Iba1040e242f015eb32651efd935ccea3514c80bc

Two new parameters (migration_interface, migration_interface_address) to make
the use of a dedicated migration network possible.

Change-Id: I723c9bea9cf1881e02ba39d5318c090960c22c47

Change-Id: Iedfad564f834504fa1f4bfd935cd735d1d9ee65f

Even though Kolla services are configured to log output to file rather than
stdout, some stdout still occurs when for example the container re(starts).
Since the Docker logs are not constrained in size, they can fill up the
docker volumes drive and bring down the host. One example of when this is
particularly problematic is when Fluentd cannot parse a log message. The
warning output is written to the Docker log and in production we have seen
it eat 100GB of disk space in less than a day. We could configure Fluentd
not to do this, but the problem may still occur via another mechanism.

Change-Id: Ia6d3935263a5909c71750b34eb69e72e6e558b7a
Closes-Bug: #1794249

Change-Id: I542b06be75991412f8e2a931ea2e40f0a0c317e4
Closes-Bug: #1758903

The Monasca Persister reads metrics from Kafka and stores them
in a configurable time series database.

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

The Monasca Notification engine generates alerts such as Slack
notifications from alerts.

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

Monasca Thresh is a Storm topology which generates alerts from
metric streams according to alarms defined via the Monasca API.

This change runs the thresholder in local mode, which means that
the log output for the topology is directed to stdout and the
topology is restarted if the container is restarted. A future
change will improve the log collection and introduce a better
way of the checking the topology is running for multi-node
clusters.

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

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

 - 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

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

Co-authored-by: Mark Goddard <mark@stackhpc.com>
Change-Id: I2e5ecf5b01cc842ec480fc4d883a7d2283fc1c31

Change-Id: I6f14d42362fc2364d967b0e2a4ebc57700fab200

To create a magnum cluster, its required to specify
'default_docker_volume_type' with some default value (default cinder
 volume type). And, it also enables users to select
diffferent cinder volume types for their volumes.

Change-Id: I50b4c436875e4daac48a14fc1e119136eb5fd844

This allows you to append additional kernel parameters
to the kernel used for inspection.

Change-Id: Ibc851145a3ffdaaad526ef999c8f024bd222dd5b

since we use chrony container to adjust time by default, we no need
to enable ntp service, this ps to disable it.

Change-Id: I2f1fd9269c9f8cfd0c98e0e903ba69de692473a0

Configure automatically ODL version based on the package version
rather than maintain a hardcoded version.

This has caused many issue while package version differs with the variable
set.

Closes-Bug: 1784784
Change-Id: I15da5d2583b5727942d598d183cc481f0e33d0e6

This is configured via the ironic_dnsmasq_default_gateway variable, and
is not set by default.

Change-Id: I4deea65876d0852ba2b48a8cf9bad94f4df2a18d

Partially-Implements: blueprint networking-baremetal

Change-Id: I92b9505843f12692aef96764a314e5db49001a9b

This patch enables the ceph mgr prometheus exporter.

If enable_prometheus_ceph_mgr_exporter is set to true,
the ceph mgr prometheus plugin is enabled on the hosts that are part
of the ceph-mgr group, then the exporter is added into the prometheus-server
configuration file.

Change-Id: Ia2f879401e585e6043f69cc5e3ab1a1f72f7f033

While it is possible to implement countermeasures against some attacks
on TLS, migrating to a later version of TLS (TLS 1.2 is strongly
encouraged) is the only reliable method to protect against
the current protocol vulnerabilities.[1]

[1] https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls

Change-Id: I44f67e3a49bb00fea069d29c46b3e86404c7df0b

It is possible to have an accessible swift API that is not managed by
kolla-ansible -- for example, ceph exposes a swift API, and using that
requires setting swift as the glance backend.

So, we should loosen the requirement that using the swift backend for
glance requires swift be enabled in kolla-ansible.

Co-Authored-By: Adam Harwell <flux.adam@gmail.com>

Change-Id: I17076d5412d2b1e1f13bb0badceaca85a5cee108

Co-Authored-By: caowei <cao.wei@99cloud.net>
Co-Authored-By: yuqian <yu.qian@99cloud.net>

Change-Id: If8143b720203fe75cf586248f1fa1d3fde34c750
blueprint: onos-support

This patchset apply Ironic rolling upgrade logic [1][2]
[1] https://docs.openstack.org/ironic/latest/contributor/rolling-upgrades.html
[2] https://docs.openstack.org/ironic/latest/admin/upgrade-guide.html#rolling-upgrades

Depends-On: https://review.openstack.org/#/c/575594/

Co-author: Ha Manh Dong <donghm@vn.fujitsu.com>
Change-Id: Id68244951dc66d5c3423ef44324bd72058f4ba67
Implements: blueprint apply-service-upgrade-procedure

This service is only required if you want to support cold migration.
In some instances that is not a needed feature, and avoiding having
another key to manage is an advantage.

Co-Authored-By: Adam Harwell <flux.adam@gmail.com>

Change-Id: I0a55a91673d9178933f134832df4bd849ddf5af4

For large installations it makes sense to use a higher number of forks
than the default.

Change-Id: I34cdc146a4ed2185fb36fbb34ab72916ec98bee5

Since chrony container is supported by kolla [1], we should enable it by
default.

[1] https://github.com/openstack/kolla-ansible/tree/master/ansible/roles/chrony

Change-Id: I1fd4dcae8da4e807b8eaefa65607671bf7a9a19a

This is a Logstash component which reads processed logs from Kafka
and writes them to Elasticsearch (or some other backend supported by
Logstash).

Ingesting the logs from this service with Fluentd will be covered under
a different commit.

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

This patch extends the prometheus role for being able
to deploy the prometheus-alertmanager[0] container.

The variable enable_prometheus_alertmanager
decides if the container should be deployed and enabled.

If enabled, the following configuration and actions are performed:

- The alerting section on the prometheus-server configuration
is added pointing the prometheus-alertmanager host group as targets.

- HAProxy is configured to load-balance over the prometheus-alertmanager
host group. (external/internal).

Please note that a default (dummy) configuration is provided, that
allows the service to start, the operator should extend it via a node custom config

[0] https://github.com/openstack/kolla/tree/master/docker/prometheus/prometheus-alertmanager



Change-Id: I3a13342c67744a278cc8d52900a913c3ccc452ae
Closes-Bug: 1774725
Signed-off-by: Jorge Niedbalski <jorge.niedbalski@linaro.org>

In some environments it may not be desirable to modify the sudoers
configuration. This change makes this part of bootstrap-servers
optional, based on the create_kolla_user_sudoers variable.

Change-Id: I653403bfc5431741807edef57df58e05e679900b

The Monasca Log Transformer takes raw, unstandardised logs from one
Kafka topic, standardises them with whatever rules the operator wants
to use, and then writes them to a standardised logs topic in Kafka. It
is currently implemented as a Logstash config file.

Since Kolla does a fairly good job of standardising logs, this service
does very little processing. However, when other sources of logs
are used, it may be useful to add rules to the Transformer, particularly
if it's not possible to standardise the logs at source.

Ingesting the logs from this service with Fluentd will be covered under
a different commit.

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

By default, kolla configure docker to use an insecure connection
with the private registry. If we want to use SSL verification we need
to add an option.

Change-Id: Id1805c9cfeb499da9bb56c70028f14c6f8bb20b6

As reported in the bug, these can grow to 10s to 100s of GB
in a month. To reduce the chance of filling the disk and
bringing down the control plane this change defines
an expiry time.

Closes-Bug: 1720113
Change-Id: I508aad1f515d5108a3d08c90318b70d0a918908c

Support Kolla Ceph to deploy blustore OSDs with Kolla-ansible.

Please refer to [1] for bluestore OSD configuration

The patch includes:
1. Set Ceph OSD store type group_vars/all.yml. The default value
is "bluestore" in Rocky.

2. Make Kolla Ceph to deploy bluestore OSDs with Kolla-ansible

3. Update gate test configuration for Ceph bluestore OSD test

[1]: specs/kolla-ceph-bluestore.rst

Partially-Implements: blueprint kolla-ceph-bluestore
Depends-On: I00eaa600a5e9ad4c1ebca2eeb523bca3d7a25128
Change-Id: I14f20a00654dff32c36d078ebb9005d91a3e60b2
Signed-off-by: Tone Zhang <tone.zhang@arm.com>

Co-Authored-By: rhcayadav <rhcayadav@gmail.com>

Change-Id: I3c2c56decbb9de86101f45592ba8135c49c49405
Closes-Bug: #1754424

There is no need to load custom ceph.conf and keyring from different
folder for gnocchi components. Just load the files from
node_custom_config/gnocchi folder.

Depends-On: I379ff17856509c9321b86c13a72eacc18f5c1202
Change-Id: Id553dff274a29d82fb1b743437e3656d6f817e52