Change-Id: I0d7c7f47e6653cf2903589a9c86798a8c6404af5

Nova always tries to create the rabbitmq user regardless of
whether RabbitMQ is enabled or not.
This ps also adds an external rabbitmq doc.

Change-Id: Iec517226e4c82ea351889b55689a3efceaadcc76

In the Xena release, Ironic removed the iSCSI driver [1]. The
recommended driver is direct, which uses HTTP to transfer the disk
image. This requires an HTTP server, and the simplest option is to use
the one currently deployed when enable_ironic_ipxe is set to true. For
this reason, this patch always enables the HTTP server running on the
conductor.

iPXE is still enabled separately, since it cannot currently be used at
the same time as PXE.

[1] https://review.opendev.org/c/openstack/ironic/+/789382

Change-Id: I30c2ad2bf2957ac544942aefae8898cdc8a61ec6

The variable octavia_amphora_flavor should be octavia_amp_flavor.

The variable for customising network and subnet was only mentioned in
the example.

Change-Id: I3ba5a7ccc2c810fea12bc48584c064738e5aa35e

This patch is adding configuration option to
manipulate with kernel option sysctl_net_ipv4_tcp_retries2.

More informations about kernel option in [1][2]
and RedHat suggestion [3] to set for DBs and HA.

[1]: https://pracucci.com/linux-tcp-rto-min-max-and-tcp-retries2.html
[2]: https://blog.cloudflare.com/when-tcp-sockets-refuse-to-die/
[3]: https://access.redhat.com/solutions/726753

Closes-Bug: #1917068
Change-Id: Ia0decbbfa4e33b1889b635f8bb1c9094567a2ce6

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

Change-Id: Id9a24c54db9a70c777e51ea10504159d5090f9a7

* 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

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

Trivial Fix

Change-Id: Ie08877e339455bed45ee467a87de9648678e88c5

Change-Id: I713f6fafe328e060a71dbb584e61603e547deaf6

The current behaviour is to support supplying a single
folder of Grafana dashboards which can then be populated
into a single folder in Grafana. Some users may wish
to have sub-folders of Dashboards, and load these into
separate dashboard folders in Grafana via a custom
provisioning file. For example, a user may have a
sub-folder of Ceph dashboards that they wish to keep
separate from OpenStack dashboards. This patch supports
sub-folders whilst not affecting the original mechanism.

Trivial-Fix

Change-Id: I9cd289a1ea79f00cee4d2ef30cbb508ac73f9767

Minor corrections to doc and release note.

Change-Id: I8a90cbac0b9a1eaa5f6c02271515f2357547f908

Per [1].

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

Change-Id: Id6f3cd158bf5d01750971249b11364b6a8631789
Closes-Bug: #1885689

Change-Id: I947c2940518c0f4872acaa977edeaca370dc9a96

Change-Id: Ie888e84a3b6e27afc23f89f643fdaa58880aae6d

Allow users to import custom grafana dashboards.
Dashboards as JSON files should be placed into
"{{ node_custom_config }}/grafana/dashboards/" folder.

Change-Id: Id0f83b8d08541b3b74649f097b10c9450201b426

Change-Id: Ief84e093829677c97c8df9a08aefca43b1e51aac

This change allows a user to forward control plane logs
directly to Elasticsearch from Fluentd, rather than via
the Monasca Log API when Monasca is enabled. The Monasca
Log API can continue to handle tenant logs.

For many use cases this is simpler, reduces resource
consumption and helps to decouple control plane logging
services from tenant logging services.

It may not always be desired, so is optional and off by
default.

Change-Id: I195e8e4b73ca8f573737355908eb30a3ef13b0d6

The Monasca alerting pipeline provides multi-tenancy alerts and
notifications. It runs as an Apache Storm topology and generally
places a significant memory and CPU burden on monitoring hosts,
particularly when there are lot of metrics. This is fine if the
alerting service is in use, but sometimes it is not. For example
you may use Prometheus for monitoring the control plane, and
wish to offer tenants a monitoring service via Monasca without
alerting and notification functionality. In this case it makes
sense to disable this part of the Monasca pipeline and this patch
adds support for that.

If the service is ever re-enabled, all alerts and notifications
should spawn back automatically since they are persisted in the
central mysql database cluster.

Change-Id: I84aa04125c621712f805f41c8efbc92c8e156db9

The Log Metrics service is an admin only service. We now have
support in Fluentd via the Prometheus plugin to create metrics
from logs. These metrics can be scraped into Monasca or Prometheus.
It therefore makes sense to deprecate this service, starting by
disabling it by default, and then removing it in the Xena release.
This should improve the stability of the Monasca metrics pipeline
by ensuring that all metrics pass via the Monasca API for
validation, and ensure that metrics generated from logs are
available to both Prometheus and Monasca users by default.

Change-Id: I704feb4434c1eece3eb00c19dc5f934fd4bc27b4

Historically Monasca Log Transformer has been for log
standardisation and processing. For example, logs from different
sources may use slightly different error levels such as WARN, 5,
or WARNING. Monasca Log Transformer is a place where these could
be 'squashed' into a single error level to simplify log searches
based on labels such as these.

However, in Kolla Ansible, we do this processing in Fluentd so
that the simpler Fluentd -> Elastic -> Kibana pipeline also
benefits. This helps to avoid spreading out log parsing
configuration over many services, with the Fluentd Monasca output
plugin being yet another potential place for processing (which
should be avoided). It therefore makes sense to remove this
service entirely, and squash any existing configuration which
can't be moved to Fluentd into the Log Perister service. I.e.
by removing this pipeline, we don't loose any functionality,
we encourage log processing to take place in Fluentd, or at least
outside of Monasca, and we make significant gains in efficiency
by removing a topic from Kafka which contains a copy of all logs
in transit.

Finally, users forwarding logs from outside the control plane,
eg. from tenant instances, should be encouraged to process the
logs at the point of sending using whichever framework they are
forwarding them with. This makes sense, because all Logstash
configuration in Monasca is only accessible by control plane
admins. A user can't typically do any processing inside Monasca,
with or without this change.

Change-Id: I65c76d0d1cd488725e4233b7e75a11d03866095c

Deprecates support for Prometheus v1.x.
In Xena support for it will be removed from Kolla Ansible.

Change-Id: I027b19621196c698e09f79af294ba1b5dbfc0516

This commit adds possibility to deploy Neutron's DHCP agents in OVN
networking scenario.

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

Change-Id: I073d04319b510182f5c1478e728c0c5bcc8799f1

Update the Monasca docs to improve security considerations.

Trivial-Fix
Change-Id: I97eb8441466f8c6abdbd66068257765bdbe32d4d

This pull request adds support for the OpenID Connect authentication
flow in Keystone and enables both ID and access token authentication
flows. The ID token configuration is designed to allow users to
authenticate via Horizon using an identity federation; whereas the
Access token is used to allow users to authenticate in the OpenStack CLI
using a federated user.

Without this PR, if one wants to configure OpenStack to use identity
federation, he/she needs to do a lot of configurations in the keystone,
Horizon, and register quite a good number of different parameters using
the CLI such as mappings, identity providers, federated protocols, and
so on. Therefore, with this PR, we propose a method for operators to
introduce/present the IdP's metadata to Kolla-ansible, and based on the
presented metadata, Kolla-ansible takes care of all of the
configurations to prepare OpenStack to work in a federated environment.

Implements: blueprint add-openid-support
Co-Authored-By: Jason Anderson <jasonanderson@uchicago.edu>
Change-Id: I0203a3470d7f8f2a54d5e126d947f540d93b8210

If the Octavia/Amphora management network is created by Kolla, support
setting the IP address family and IPv6 address/RA mode.

Closes-Bug: 1913409

Change-Id: I9f2ef2196654c91596cb5c4b3c157bcee267226a

There are inconsitencies across the documentation and the source code files
when it comes to project's name (Kolla Ansible vs. Kolla-Ansible). This
commit aims at unifying it so that the naming becomes consistent everywhere.

Change-Id: I903b2e08f5458b1a1abc4af3abefe20b66c23a54

Update for the example command line options.

Change-Id: Ida6e882d1014cdc5e55383a5d5ba8fa0e824a693

It is now possible to deploy either 1.x or 2.x version of Prometheus.
The new 2.x version introduces breaking changes in terms of storage
format and command line options.

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

and drop the reference to ceph-deploy (seems abandoned).

Change-Id: I763317a6f8207357991c23fa5a2fc8cc6f8a17f4

docs site cann't render it correctly without the space.
see: https://docs.openstack.org/kolla-ansible/latest/reference/networking/dpdk.html
trivial fix

Change-Id: I3ebea8c1ab76f2aaac80f3e2f7a84cd69c018ae6

Qinling project is retiring in Wallaby cycle[1].
This commit removes the ansible roles of Qinling project
before its code is removed.

Needed-By: https://review.opendev.org/c/openstack/qinling/+/764521

[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-November/018638.html

Change-Id: I6543bacff638b1649511f7e779807954c34ef570

Currently just covers deployment of Magnum. Usage information may be
added in future.

Change-Id: I3c1594c73be8e6805f80d51aad2343c084650bc2

* make each section independent
* move enable flags to specific sections
* move inventory changes to Cinder section
* move Nova config that is actually for Cinder volumes to Cinder section
* add an introduction about each integration

Change-Id: Ie8d82010bf8d5b8af2c039f285744e5ae67316dc

just like the ". /etc/kolla/admin-openrc.sh" [1]

[1]: https://github.com/openstack/kolla-ansible/blob/master/doc/source/user/quickstart.rst

Change-Id: I9c288f31c36654f2ec49e6b3b0fcfc1178e4ad90

Change-Id: I733d412ba6c92c2c9bcc2e9681d6ac8333fb661b
Implements: blueprint implement-automatic-deploy-of-octavia

Follows existing backends patterns to add support for the GlusterFS
NFS driver.
NFS server type used by the GlusterFS backend, Gluster or Ganesha,
currently supports Gluster.
The GlusterFS NFS driver needs to install the glusterfs-fuse package
in the kolla images manila share container in advance, which has been merged
in https://review.opendev.org/747510

Change-Id: I7fdb121b5bf9850d62246a24f9b17d226028c2ca

Nova has reversed their deprecation of the VMware driver, and the Kolla
community has shown an interest in it.

Change-Id: I82f1074da56ed16c08317d1f92ed7f0a6f4a149a