[docs] Unify project's naming convention

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
This commit is contained in:
Piotr Parczewski 2021-01-18 23:14:14 +01:00
parent 01c0c39fb0
commit 5db72659a0
19 changed files with 82 additions and 82 deletions

View File

@ -1,5 +1,5 @@
============= =============
Kolla-Ansible Kolla Ansible
============= =============
.. image:: https://governance.openstack.org/tc/badges/kolla-ansible.svg .. image:: https://governance.openstack.org/tc/badges/kolla-ansible.svg
@ -8,9 +8,9 @@ Kolla-Ansible
.. Change things from this point on .. Change things from this point on
The Kolla-Ansible is a deliverable project separated from Kolla project. The Kolla Ansible is a deliverable project separated from Kolla project.
Kolla-Ansible deploys OpenStack services and infrastructure components Kolla Ansible deploys OpenStack services and infrastructure components
in Docker containers. in Docker containers.
Kolla's mission statement is: Kolla's mission statement is:
@ -28,8 +28,8 @@ configuration to suit the operator's exact requirements.
Getting Started Getting Started
=============== ===============
Learn about Kolla-Ansible by reading the documentation online Learn about Kolla Ansible by reading the documentation online
`Kolla-Ansible <https://docs.openstack.org/kolla-ansible/latest/>`__. `Kolla Ansible <https://docs.openstack.org/kolla-ansible/latest/>`__.
Get started by reading the `Developer Get started by reading the `Developer
Quickstart <https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html>`__. Quickstart <https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html>`__.
@ -37,7 +37,7 @@ Quickstart <https://docs.openstack.org/kolla-ansible/latest/user/quickstart.html
OpenStack services OpenStack services
------------------ ------------------
Kolla-Ansible deploys containers for the following OpenStack projects: Kolla Ansible deploys containers for the following OpenStack projects:
- `Aodh <https://docs.openstack.org/aodh/latest/>`__ - `Aodh <https://docs.openstack.org/aodh/latest/>`__
- `Barbican <https://docs.openstack.org/barbican/latest/>`__ - `Barbican <https://docs.openstack.org/barbican/latest/>`__
@ -81,7 +81,7 @@ Kolla-Ansible deploys containers for the following OpenStack projects:
Infrastructure components Infrastructure components
------------------------- -------------------------
Kolla-Ansible deploys containers for the following infrastructure components: Kolla Ansible deploys containers for the following infrastructure components:
- `Collectd <https://collectd.org/>`__, - `Collectd <https://collectd.org/>`__,
`Telegraf <https://docs.influxdata.com/telegraf/>`__, `Telegraf <https://docs.influxdata.com/telegraf/>`__,
@ -121,11 +121,11 @@ Directories
a working All-in-One (AIO) deployment. a working All-in-One (AIO) deployment.
- ``kolla_ansible`` - Contains password generation script. - ``kolla_ansible`` - Contains password generation script.
- ``releasenotes`` - Contains releasenote of all features added in - ``releasenotes`` - Contains releasenote of all features added in
Kolla-Ansible. Kolla Ansible.
- ``specs`` - Contains the Kolla-Ansible communities key arguments about - ``specs`` - Contains the Kolla Ansible communities key arguments about
architectural shifts in the code base. architectural shifts in the code base.
- ``tests`` - Contains functional testing tools. - ``tests`` - Contains functional testing tools.
- ``tools`` - Contains tools for interacting with Kolla-Ansible. - ``tools`` - Contains tools for interacting with Kolla Ansible.
- ``zuul.d`` - Contains project gate job definitions. - ``zuul.d`` - Contains project gate job definitions.
Getting Involved Getting Involved

View File

@ -1,10 +1,10 @@
--- ---
# This play adapts https://docs.openstack.org/octavia/victoria/admin/guides/certificates.html # This play adapts https://docs.openstack.org/octavia/victoria/admin/guides/certificates.html
# Kolla-Ansible prepares the Server CA certificate and key for use by Octavia # Kolla Ansible prepares the Server CA certificate and key for use by Octavia
# to generate Amphorae certificates. # to generate Amphorae certificates.
# Kolla-Ansible prepares and controls the Client CA certificate and key. # Kolla Ansible prepares and controls the Client CA certificate and key.
# Client CA is used to generate certificates for Octavia controllers. # Client CA is used to generate certificates for Octavia controllers.
- name: Ensure server_ca and client_ca directories exist - name: Ensure server_ca and client_ca directories exist

View File

@ -165,7 +165,7 @@ octavia_amp_image_tag: "amphora"
# Load balancer topology options are [ SINGLE, ACTIVE_STANDBY ] # Load balancer topology options are [ SINGLE, ACTIVE_STANDBY ]
octavia_loadbalancer_topology: "SINGLE" octavia_loadbalancer_topology: "SINGLE"
# Whether to run Kolla-Ansible's automatic configuration for Octavia. # Whether to run Kolla Ansible's automatic configuration for Octavia.
# NOTE: if you upgrade from Ussuri, you must set `octavia_auto_configure` to `no` # NOTE: if you upgrade from Ussuri, you must set `octavia_auto_configure` to `no`
# and keep your other Octavia config like before. # and keep your other Octavia config like before.
octavia_auto_configure: yes octavia_auto_configure: yes

View File

@ -54,7 +54,7 @@ source_suffix = '.rst'
master_doc = 'index' master_doc = 'index'
# General information about the project. # General information about the project.
project = 'Kolla-Ansible' project = 'Kolla Ansible'
bug_tag = 'deploy-guide' bug_tag = 'deploy-guide'
copyright = '2016, OpenStack contributors' copyright = '2016, OpenStack contributors'

View File

@ -1,5 +1,5 @@
============================== ==============================
Kolla-Ansible Deployment Guide Kolla Ansible Deployment Guide
============================== ==============================
Kolla provides Docker containers and Ansible playbooks to meet Kolla's mission. Kolla provides Docker containers and Ansible playbooks to meet Kolla's mission.

View File

@ -4,7 +4,7 @@
MariaDB database backup and restore MariaDB database backup and restore
=================================== ===================================
Kolla-Ansible can facilitate either full or incremental backups of data Kolla Ansible can facilitate either full or incremental backups of data
hosted in MariaDB. It achieves this using Mariabackup, a tool hosted in MariaDB. It achieves this using Mariabackup, a tool
designed to allow for 'hot backups' - an approach which means that consistent designed to allow for 'hot backups' - an approach which means that consistent
backups can be taken without any downtime for your database or your cloud. backups can be taken without any downtime for your database or your cloud.
@ -60,7 +60,7 @@ permissions defined during the configuration step; no password is required to
invoke these commands. invoke these commands.
Furthermore, backup actions can be triggered from a node with a minimal Furthermore, backup actions can be triggered from a node with a minimal
installation of Kolla-Ansible, specifically one which doesn't require a copy of installation of Kolla Ansible, specifically one which doesn't require a copy of
``passwords.yml``. This is of note if you're looking to implement automated ``passwords.yml``. This is of note if you're looking to implement automated
backups scheduled via a cron job. backups scheduled via a cron job.

View File

@ -37,7 +37,7 @@ source_suffix = '.rst'
master_doc = 'index' master_doc = 'index'
# General information about the project. # General information about the project.
project = 'kolla-ansible' project = 'Kolla Ansible'
copyright = '2013, OpenStack Foundation' copyright = '2013, OpenStack Foundation'
# If true, '()' will be appended to :func: etc. cross-reference text. # If true, '()' will be appended to :func: etc. cross-reference text.
@ -67,15 +67,15 @@ html_theme_options = {
} }
# Output file base name for HTML help builder. # Output file base name for HTML help builder.
htmlhelp_basename = '%sdoc' % project htmlhelp_basename = 'kolla-ansibledoc'
# Grouping the document tree into LaTeX files. List of tuples # Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, documentclass # (source start file, target name, title, author, documentclass
# [howto/manual]). # [howto/manual]).
latex_documents = [ latex_documents = [
('index', ('index',
'doc-%s.tex' % project, 'doc-kolla-ansible.tex',
'%s Documentation' % project, 'Kolla Ansible Documentation',
'OpenStack Foundation', 'manual'), 'OpenStack Foundation', 'manual'),
] ]

View File

@ -127,4 +127,4 @@ Project Team Lead Duties
~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~
All common PTL duties are enumerated in the `PTL guide <https://docs.openstack.org/project-team-guide/ptl.html>`_. All common PTL duties are enumerated in the `PTL guide <https://docs.openstack.org/project-team-guide/ptl.html>`_.
Kolla-Ansible-specific PTL duties are listed in `Kolla Ansible PTL guide <https://docs.openstack.org/kolla-ansible/latest/contributor/ptl-guide.html>`_. Kolla Ansible-specific PTL duties are listed in `Kolla Ansible PTL guide <https://docs.openstack.org/kolla-ansible/latest/contributor/ptl-guide.html>`_.

View File

@ -15,13 +15,13 @@
under the License. under the License.
========================================= =========================================
Welcome to Kolla-Ansible's documentation! Welcome to Kolla Ansible's documentation!
========================================= =========================================
Kolla's mission is to provide production-ready containers and deployment tools Kolla's mission is to provide production-ready containers and deployment tools
for operating OpenStack clouds. for operating OpenStack clouds.
Kolla-Ansible is highly opinionated out of the box, but allows for complete Kolla Ansible is highly opinionated out of the box, but allows for complete
customization. This permits operators with minimal experience to deploy customization. This permits operators with minimal experience to deploy
OpenStack quickly and as experience grows modify the OpenStack configuration to OpenStack quickly and as experience grows modify the OpenStack configuration to
suit the operator's exact requirements. suit the operator's exact requirements.
@ -31,7 +31,7 @@ Related Projects
This documentation is for Kolla Ansible. This documentation is for Kolla Ansible.
For information on building container images for use with Kolla-Ansible, please For information on building container images for use with Kolla Ansible, please
refer to the `Kolla image documentation refer to the `Kolla image documentation
<https://docs.openstack.org/kolla/latest/>`_. <https://docs.openstack.org/kolla/latest/>`_.
@ -44,8 +44,8 @@ Site Notes
This documentation is continually updated and may not represent the state of This documentation is continually updated and may not represent the state of
the project at any specific prior release. To access documentation for a the project at any specific prior release. To access documentation for a
previous release of kolla, append the OpenStack release name to the URL. For previous release of Kolla Ansible, append the OpenStack release name to the
example, to access Kolla Ansible documentation for the Stein release: URL. For example, to access documentation for the Stein release:
https://docs.openstack.org/kolla-ansible/stein https://docs.openstack.org/kolla-ansible/stein
Release Notes Release Notes

View File

@ -159,7 +159,7 @@ Configure and Deploy a Bifrost Container
This section provides instructions for how to configure and deploy a container This section provides instructions for how to configure and deploy a container
running bifrost services. running bifrost services.
Prepare Kolla-Ansible Inventory Prepare Kolla Ansible Inventory
------------------------------- -------------------------------
Kolla-ansible will deploy bifrost on the hosts in the ``bifrost`` Ansible Kolla-ansible will deploy bifrost on the hosts in the ``bifrost`` Ansible
@ -177,7 +177,7 @@ services deployed by kolla including OpenStack Ironic, MariaDB, RabbitMQ and
(optionally) OpenStack Keystone. These services should not be deployed on the (optionally) OpenStack Keystone. These services should not be deployed on the
host on which bifrost is deployed. host on which bifrost is deployed.
Prepare Kolla-Ansible Configuration Prepare Kolla Ansible Configuration
----------------------------------- -----------------------------------
Follow the instructions in :doc:`../../user/quickstart` to prepare Follow the instructions in :doc:`../../user/quickstart` to prepare
@ -291,7 +291,7 @@ Deploy Bifrost
The bifrost container can be deployed either using kolla-ansible or manually. The bifrost container can be deployed either using kolla-ansible or manually.
Deploy Bifrost using Kolla-Ansible Deploy Bifrost using Kolla Ansible
---------------------------------- ----------------------------------
For development: For development:
@ -382,7 +382,7 @@ Once we have deployed a bifrost container we can use it to provision the bare
metal cloud hosts specified in the inventory file. Again, this can be done metal cloud hosts specified in the inventory file. Again, this can be done
either using kolla-ansible or manually. either using kolla-ansible or manually.
By Kolla-Ansible By Kolla Ansible
---------------- ----------------
For Development: For Development:

View File

@ -214,7 +214,7 @@ choosing *import* option.
Custom log rules Custom log rules
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~
Kolla-Ansible automatically deploys Fluentd for forwarding OpenStack logs Kolla Ansible automatically deploys Fluentd for forwarding OpenStack logs
from across the control plane to a central logging repository. The Fluentd from across the control plane to a central logging repository. The Fluentd
configuration is split into four parts: Input, forwarding, filtering and configuration is split into four parts: Input, forwarding, filtering and
formatting. The following can be customised: formatting. The following can be customised:

View File

@ -49,19 +49,19 @@ following override in ``/etc/kolla/globals.yml``:
Stand-alone configuration (optional) Stand-alone configuration (optional)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Monasca can be deployed via Kolla-Ansible in a standalone configuration. The Monasca can be deployed via Kolla Ansible in a standalone configuration. The
deployment will include all supporting services such as HAProxy, Keepalived, deployment will include all supporting services such as HAProxy, Keepalived,
MariaDB and Memcached. It can also include Keystone, but you will likely MariaDB and Memcached. It can also include Keystone, but you will likely
want to integrate with the Keystone instance provided by your existing want to integrate with the Keystone instance provided by your existing
OpenStack deployment. Some reasons to perform a standalone deployment are: OpenStack deployment. Some reasons to perform a standalone deployment are:
* Your OpenStack deployment is *not* managed by Kolla-Ansible, but you want * Your OpenStack deployment is *not* managed by Kolla Ansible, but you want
to take advantage of Monasca support in Kolla-Ansible. to take advantage of Monasca support in Kolla Ansible.
* Your OpenStack deployment *is* managed by Kolla-Ansible, but you do not * Your OpenStack deployment *is* managed by Kolla Ansible, but you do not
want the Monasca deployment to share services with your OpenStack want the Monasca deployment to share services with your OpenStack
deployment. For example, in a combined deployment Monasca will share HAProxy deployment. For example, in a combined deployment Monasca will share HAProxy
and MariaDB with the core OpenStack services. and MariaDB with the core OpenStack services.
* Your OpenStack deployment *is* managed by Kolla-Ansible, but you want * Your OpenStack deployment *is* managed by Kolla Ansible, but you want
Monasca to be decoupled from the core OpenStack services. For example, you Monasca to be decoupled from the core OpenStack services. For example, you
may have a dedicated monitoring and logging team, and wish to prevent that may have a dedicated monitoring and logging team, and wish to prevent that
team accidentally breaking, or redeploying core OpenStack services. team accidentally breaking, or redeploying core OpenStack services.
@ -112,7 +112,7 @@ be obtained from the external OpenStack CLI, for example:
| e02067a58b1946c7ae53abf0cfd0bf11 | RegionOne | keystone | identity | True | internal | http://172.28.128.254:5000 | | e02067a58b1946c7ae53abf0cfd0bf11 | RegionOne | keystone | identity | True | internal | http://172.28.128.254:5000 |
+----------------------------------+-----------+--------------+--------------+---------+-----------+-----------------------------+ +----------------------------------+-----------+--------------+--------------+---------+-----------+-----------------------------+
If you are also using Kolla-Ansible to manage the external OpenStack If you are also using Kolla Ansible to manage the external OpenStack
installation, the external Keystone admin password will most likely installation, the external Keystone admin password will most likely
be defined in the *external* `/etc/kolla/passwords.yml` file. For other be defined in the *external* `/etc/kolla/passwords.yml` file. For other
deployment methods you will need to consult the relevant documentation. deployment methods you will need to consult the relevant documentation.

View File

@ -51,7 +51,7 @@ and versioning may differ depending on deploy configuration):
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
97d25657d55e operator:5000/kolla/centos-source-neutron-vpnaas-agent:4.0.0 "kolla_start" 44 minutes ago Up 44 minutes neutron_vpnaas_agent 97d25657d55e operator:5000/kolla/centos-source-neutron-vpnaas-agent:4.0.0 "kolla_start" 44 minutes ago Up 44 minutes neutron_vpnaas_agent
Kolla-Ansible includes a small script that can be used in tandem with Kolla Ansible includes a small script that can be used in tandem with
``tools/init-runonce`` to verify the VPN using two routers and two Nova VMs: ``tools/init-runonce`` to verify the VPN using two routers and two Nova VMs:
.. code-block:: console .. code-block:: console

View File

@ -71,7 +71,7 @@ the following:
neutron_plugin_agent: "ovn" neutron_plugin_agent: "ovn"
When using OVN - Kolla-Ansible will not enable distributed floating ip When using OVN - Kolla Ansible will not enable distributed floating ip
functionality (not enable external bridges on computes) by default. functionality (not enable external bridges on computes) by default.
To change this behaviour you need to set the following: To change this behaviour you need to set the following:

View File

@ -297,7 +297,7 @@ Enable Swift Recon in ``/etc/kolla/globals.yml``:
enable_swift_recon : "yes" enable_swift_recon : "yes"
The Swift role in Kolla-Ansible is still using the old role format. Unlike many The Swift role in Kolla Ansible is still using the old role format. Unlike many
other Kolla Ansible roles, it won't automatically add the new volume to the other Kolla Ansible roles, it won't automatically add the new volume to the
containers in existing deployments when running `kolla-ansible reconfigure`. containers in existing deployments when running `kolla-ansible reconfigure`.
Instead we must use the `kolla-ansible upgrade` command, which will remove the Instead we must use the `kolla-ansible upgrade` command, which will remove the

View File

@ -97,7 +97,7 @@ Edit the Inventory File
The ansible inventory file contains all the information needed to determine The ansible inventory file contains all the information needed to determine
what services will land on which hosts. Edit the inventory file in the what services will land on which hosts. Edit the inventory file in the
Kolla-Ansible directory ``ansible/inventory/multinode``. If Kolla-Ansible Kolla Ansible directory ``ansible/inventory/multinode``. If Kolla Ansible
was installed with pip, it can be found in ``/usr/share/kolla-ansible``. was installed with pip, it can be found in ``/usr/share/kolla-ansible``.
Add the IP addresses or hostnames to a group and the services associated with Add the IP addresses or hostnames to a group and the services associated with

View File

@ -11,7 +11,7 @@ Recommended reading
~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
It's beneficial to learn basics of both `Ansible <https://docs.ansible.com>`__ It's beneficial to learn basics of both `Ansible <https://docs.ansible.com>`__
and `Docker <https://docs.docker.com>`__ before running Kolla-Ansible. and `Docker <https://docs.docker.com>`__ before running Kolla Ansible.
Host machine requirements Host machine requirements
~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~
@ -276,7 +276,7 @@ The next step is to prepare our inventory file. An inventory is an Ansible file
where we specify hosts and the groups that they belong to. We can use this to where we specify hosts and the groups that they belong to. We can use this to
define node roles and access credentials. define node roles and access credentials.
Kolla-Ansible comes with ``all-in-one`` and ``multinode`` example inventory Kolla Ansible comes with ``all-in-one`` and ``multinode`` example inventory
files. The difference between them is that the former is ready for deploying files. The difference between them is that the former is ready for deploying
single node OpenStack on localhost. If you need to use separate host or more single node OpenStack on localhost. If you need to use separate host or more
than one node, edit ``multinode`` inventory: than one node, edit ``multinode`` inventory:
@ -351,8 +351,8 @@ For development, run:
Kolla globals.yml Kolla globals.yml
----------------- -----------------
``globals.yml`` is the main configuration file for Kolla-Ansible. ``globals.yml`` is the main configuration file for Kolla Ansible.
There are a few options that are required to deploy Kolla-Ansible: There are a few options that are required to deploy Kolla Ansible:
* Image options * Image options
@ -399,7 +399,7 @@ There are a few options that are required to deploy Kolla-Ansible:
* Networking * Networking
Kolla-Ansible requires a few networking options to be set. Kolla Ansible requires a few networking options to be set.
We need to set network interfaces used by OpenStack. We need to set network interfaces used by OpenStack.
First interface to set is "network_interface". This is the default interface First interface to set is "network_interface". This is the default interface
@ -433,7 +433,7 @@ There are a few options that are required to deploy Kolla-Ansible:
* Enable additional services * Enable additional services
By default Kolla-Ansible provides a bare compute kit, however it does provide By default Kolla Ansible provides a bare compute kit, however it does provide
support for a vast selection of additional services. To enable them, set support for a vast selection of additional services. To enable them, set
``enable_*`` to "yes". For example, to enable Block Storage service: ``enable_*`` to "yes". For example, to enable Block Storage service:
@ -475,7 +475,7 @@ Deployment
After configuration is set, we can proceed to the deployment phase. First we After configuration is set, we can proceed to the deployment phase. First we
need to setup basic host-level dependencies, like docker. need to setup basic host-level dependencies, like docker.
Kolla-Ansible provides a playbook that will install all required services in Kolla Ansible provides a playbook that will install all required services in
the correct versions. the correct versions.
The following assumes the use of the ``multinode`` inventory. If using a The following assumes the use of the ``multinode`` inventory. If using a
@ -554,7 +554,7 @@ Using OpenStack
./kolla-ansible post-deploy ./kolla-ansible post-deploy
. /etc/kolla/admin-openrc.sh . /etc/kolla/admin-openrc.sh
#. Depending on how you installed Kolla-Ansible, there is a script that will #. Depending on how you installed Kolla Ansible, there is a script that will
create example networks, images, and so on. create example networks, images, and so on.
* For deployment or evaluation, * For deployment or evaluation,

View File

@ -718,7 +718,7 @@
########################################## ##########################################
# Octavia - openstack loadbalancer Options # Octavia - openstack loadbalancer Options
########################################## ##########################################
# Whether to run Kolla-Ansible's automatic configuration for Octavia. # Whether to run Kolla Ansible's automatic configuration for Octavia.
# NOTE: if you upgrade from Ussuri, you must set `octavia_auto_configure` to `no` # NOTE: if you upgrade from Ussuri, you must set `octavia_auto_configure` to `no`
# and keep your other Octavia config like before. # and keep your other Octavia config like before.
#octavia_auto_configure: yes #octavia_auto_configure: yes

View File

@ -4,16 +4,16 @@ Prometheus Monitoring
https://blueprints.launchpad.net/kolla-ansible/+spec/prometheus https://blueprints.launchpad.net/kolla-ansible/+spec/prometheus
One of the challenges faced by Kolla-Ansible operators, particularly of large One of the challenges faced by Kolla Ansible operators, particularly of large
deployments, is monitoring the behavior and performance of the nodes. To help deployments, is monitoring the behavior and performance of the nodes. To help
address this concern, it is proposed that Kolla-Ansible use Prometheus [1]_ as a address this concern, it is proposed that Kolla Ansible use Prometheus [1]_ as a
framework for introducing monitoring capabilities. framework for introducing monitoring capabilities.
Prometheus is a widely adopted and supported tool for monitoring, capable of Prometheus is a widely adopted and supported tool for monitoring, capable of
monitoring both system and service level characteristics. Many projects have monitoring both system and service level characteristics. Many projects have
existing support for exporting data in Prometheus format either directly from existing support for exporting data in Prometheus format either directly from
the product itself or via a separate exporter [2]_. This includes several tools the product itself or via a separate exporter [2]_. This includes several tools
used as part of the Kolla-Ansible software stack, meaning that with minimal work used as part of the Kolla Ansible software stack, meaning that with minimal work
we could provide visibility into the performance characteristics of some of the we could provide visibility into the performance characteristics of some of the
underlying software frameworks. There are also exporters to do system underlying software frameworks. There are also exporters to do system
performance monitoring which could provide further visibility into the health of performance monitoring which could provide further visibility into the health of
@ -39,11 +39,11 @@ collected by Prometheus.
Use Cases Use Cases
--------- ---------
1. Query performance characteristics of nodes or other components in 1. Query performance characteristics of nodes or other components in
Kolla-Ansible software stack (more details about what components can be Kolla Ansible software stack (more details about what components can be
monitored is given below) monitored is given below)
2. Display dashboard illustrating overall system performance of Kolla-Ansible 2. Display dashboard illustrating overall system performance of Kolla Ansible
nodes nodes
3. Determine high-level status of Kolla-Ansible containers and identify 3. Determine high-level status of Kolla Ansible containers and identify
potential issues encountered during deployment potential issues encountered during deployment
Proposed change Proposed change
@ -57,7 +57,7 @@ solution is to expose the data so that Prometheus can access it.
Some tools natively expose data in a useful format. In these cases all that is Some tools natively expose data in a useful format. In these cases all that is
necessary is proper configuration of the tool to ensure the data is exported on necessary is proper configuration of the tool to ensure the data is exported on
a known port and configuration of the Kolla-Ansible container to expose the a known port and configuration of the Kolla Ansible container to expose the
relevant port such that Prometheus can access the data. relevant port such that Prometheus can access the data.
Most tools, however, use exporters or collectors that run as separate processes Most tools, however, use exporters or collectors that run as separate processes
@ -65,28 +65,28 @@ from the tool itself. These collect data using exposed APIs and format the data
in a manner that can be collected by Prometheus. In these cases, each exporter in a manner that can be collected by Prometheus. In these cases, each exporter
would be run on a separate container from the main process. This will require would be run on a separate container from the main process. This will require
building of the requisite containers as well as modifications to the building of the requisite containers as well as modifications to the
Kolla-Ansible deployment to run these containers during deployment. Furthermore, Kolla Ansible deployment to run these containers during deployment. Furthermore,
each exporter requires configuration of the Prometheus server to configure it to each exporter requires configuration of the Prometheus server to configure it to
scrape the data. scrape the data.
Listed below are some of the exporters that already exist for Prometheus that Listed below are some of the exporters that already exist for Prometheus that
are related to components of a typical OpenStack Kolla-Ansible deployment. This are related to components of a typical OpenStack Kolla Ansible deployment. This
is based largely on the list of Prometheus Exporters and Integrations [2]_, and is based largely on the list of Prometheus Exporters and Integrations [2]_, and
links to more information about each exporter can be found there. Although we links to more information about each exporter can be found there. Although we
could choose to expose any of these exporters through Kolla-Ansible, it is not could choose to expose any of these exporters through Kolla Ansible, it is not
expected that we will implement all of these initially. It is proposed that we expected that we will implement all of these initially. It is proposed that we
start with the exporters for which Kolla containers already exist. cAdvisor is start with the exporters for which Kolla containers already exist. cAdvisor is
also recommended for early implementation since it provides more detailed also recommended for early implementation since it provides more detailed
metrics for Docker container performance. We can investigate and add exporters metrics for Docker container performance. We can investigate and add exporters
for additional services as time allows, but how far we proceed will depend for additional services as time allows, but how far we proceed will depend
largely on the level of interest amongst Kolla-Ansible developers who might help largely on the level of interest amongst Kolla Ansible developers who might help
do the work. do the work.
Existing Kolla Containers Existing Kolla Containers
^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^
The following exporters already have associated Kolla containers (used in The following exporters already have associated Kolla containers (used in
Kolla-Kubernetes) and therefore should be minimal work to make available for a Kolla-Kubernetes) and therefore should be minimal work to make available for a
Kolla-Ansible deployment: Kolla Ansible deployment:
* HAProxy * HAProxy
* MySQL * MySQL
@ -130,14 +130,14 @@ are. The cAdvisor exporter also exposes information about containers (and
provides more detailed view into specific containers than the built-in Docker provides more detailed view into specific containers than the built-in Docker
metrics), but the high-level state of the container is still not available. metrics), but the high-level state of the container is still not available.
Determining which containers may have failed to start or are in the 'restarting' Determining which containers may have failed to start or are in the 'restarting'
state is one of the first troubleshooting steps of a broken Kolla-Ansible state is one of the first troubleshooting steps of a broken Kolla Ansible
deployment, so this is a significant shortcoming. Therefore, it is proposed deployment, so this is a significant shortcoming. Therefore, it is proposed
that a simple Prometheus collector be implemented that exposes this data to that a simple Prometheus collector be implemented that exposes this data to
Prometheus. Prometheus.
Initially this collector will be quite simple, but more functionality can be Initially this collector will be quite simple, but more functionality can be
added if and when we find more critical data missing from the existing set of added if and when we find more critical data missing from the existing set of
exporters or when additional health checking becomes available for Kolla-Ansible exporters or when additional health checking becomes available for Kolla Ansible
containers [3]_. The key metric exposed by this collector is a gauge called containers [3]_. The key metric exposed by this collector is a gauge called
kolla_containers and has two labels, name and state which refer respectively to kolla_containers and has two labels, name and state which refer respectively to
the name of the container (e.g. cinder_volume) and the container state (e.g. the name of the container (e.g. cinder_volume) and the container state (e.g.
@ -148,7 +148,7 @@ the container with that name is in the indicated state).
A few examples of useful queries on this data include: A few examples of useful queries on this data include:
* Total number of Kolla-Ansible containers across all nodes: * Total number of Kolla Ansible containers across all nodes:
``sum(kolla_containers)`` ``sum(kolla_containers)``
* Number of containers in each state on each node: ``sum(kolla_containers) by * Number of containers in each state on each node: ``sum(kolla_containers) by
(instance)`` (instance)``
@ -164,7 +164,7 @@ The Kolla-Container collector uses the docker api to query this data and
connects via the unix socket. It will use Python docker module to connect to connects via the unix socket. It will use Python docker module to connect to
docker and the Prometheus_client module to expose this data in Prometheus docker and the Prometheus_client module to expose this data in Prometheus
format. It will filter the docker containers based on container label to only format. It will filter the docker containers based on container label to only
expose statistics for Kolla-Ansible containers. Additionally, the collector expose statistics for Kolla Ansible containers. Additionally, the collector
should expose certain standard metrics exposed by most collectors such as the should expose certain standard metrics exposed by most collectors such as the
scrape duration which represents the performance characteristics of the scrape duration which represents the performance characteristics of the
collector itself. collector itself.
@ -175,11 +175,11 @@ the standard Ansible deployment.
Running Prometheus Running Prometheus
------------------ ------------------
Prometheus itself will run inside a container on each node in the existing Prometheus itself will run inside a container on each node in the existing
Kolla-Ansible monitoring inventory group. A Prometheus container already exists Kolla Ansible monitoring inventory group. A Prometheus container already exists
in the Kolla repository (initially provided for Kolla-Kubernetes) and this in the Kolla repository (initially provided for Kolla-Kubernetes) and this
container can be used in Kolla-Ansible deployment as well. container can be used in Kolla Ansible deployment as well.
Additions will be required to the Kolla-Ansible deployment process to run this Additions will be required to the Kolla Ansible deployment process to run this
container. Since this monitoring tool is useful in determining the state of container. Since this monitoring tool is useful in determining the state of
deployment and analyzing problems that may occur during deployment, the deployment and analyzing problems that may occur during deployment, the
container should be started as early as possible during deployment. Although container should be started as early as possible during deployment. Although
@ -190,7 +190,7 @@ MySQL exporter requires database user creation to function.
We should also expose Prometheus via HAProxy so that Prometheus data can be We should also expose Prometheus via HAProxy so that Prometheus data can be
queried using the virtual IP that is used to access other OpenStack APIs and queried using the virtual IP that is used to access other OpenStack APIs and
browser UIs. This also will require modifications to the existing HAProxy browser UIs. This also will require modifications to the existing HAProxy
configuration template in the Kolla-Ansible repository. configuration template in the Kolla Ansible repository.
In the initial implementation, Prometheus will use local data storage for its In the initial implementation, Prometheus will use local data storage for its
metrics. This means that Prometheus data is not HA and there will be data metrics. This means that Prometheus data is not HA and there will be data
@ -213,14 +213,14 @@ framework. Once that is done an operator can create or import dashboards that
make use of this data. make use of this data.
It would also be possible to define one or more default, preloaded dashboards It would also be possible to define one or more default, preloaded dashboards
for Grafana to display the information deemed most useful for Kolla-Ansible for Grafana to display the information deemed most useful for Kolla Ansible
deployment monitoring. Grafana also has plugins that provide diagrams [5]_ that deployment monitoring. Grafana also has plugins that provide diagrams [5]_ that
could help visualize the state of the Kolla-Ansible deployment. The amount of could help visualize the state of the Kolla Ansible deployment. The amount of
work that can be done in this area will depend upon the level of developer work that can be done in this area will depend upon the level of developer
interest and involvement in the project. interest and involvement in the project.
The addition of the data exported by the proposed Kolla-Container Exporter The addition of the data exported by the proposed Kolla-Container Exporter
provides a useful tool for checking the state of a Kolla-Ansible deployment. By provides a useful tool for checking the state of a Kolla Ansible deployment. By
analyzing the data from this exporter, a tool can provide high-level deployment analyzing the data from this exporter, a tool can provide high-level deployment
status. This functionality should be provided via a new status command within status. This functionality should be provided via a new status command within
the kolla-ansible command (or via a CLI if one is introduced [6]_). Information the kolla-ansible command (or via a CLI if one is introduced [6]_). Information
@ -237,12 +237,12 @@ to be displayed will include:
with the collector or with deployment of the collector, or it might just with the collector or with deployment of the collector, or it might just
indicate that deployment has not yet proceeded to the point where the indicate that deployment has not yet proceeded to the point where the
collector has been started. collector has been started.
* Kolla-Ansible containers that are not in the running state should be listed. * Kolla Ansible containers that are not in the running state should be listed.
For example, containers in a restarting state may represent a misconfiguration For example, containers in a restarting state may represent a misconfiguration
of the cluster and should be identified. of the cluster and should be identified.
* Other health statistics: on a normally running cluster, some basic statistics * Other health statistics: on a normally running cluster, some basic statistics
can be provided to help identify potential problems. The set of statistics can be provided to help identify potential problems. The set of statistics
should include such details as the total number of running Kolla-Ansible should include such details as the total number of running Kolla Ansible
containers on each system (an unexpectedly low number on one or more systems containers on each system (an unexpectedly low number on one or more systems
might indicate a problem). Other details can be added in the future as deemed might indicate a problem). Other details can be added in the future as deemed
necessary. necessary.
@ -257,8 +257,8 @@ left for a future blueprint.
Configuration Configuration
------------- -------------
As with all optional services in Kolla-Ansible, Prometheus deployment should be As with all optional services in Kolla Ansible, Prometheus deployment should be
controlled by Kolla-Ansible variables. A high level enable_prometheus variable controlled by Kolla Ansible variables. A high level enable_prometheus variable
should control whether Prometheus is used at all. Additionally, additional should control whether Prometheus is used at all. Additionally, additional
variables can be used to control individual exporters. For example, variables can be used to control individual exporters. For example,
enable_prometheus_haproxy could be used to enable/disable the HAProxy exporter enable_prometheus_haproxy could be used to enable/disable the HAProxy exporter
@ -306,7 +306,7 @@ have a measurable impact on the system.
Any potential risk to performance may be mitigated in several ways. Each Any potential risk to performance may be mitigated in several ways. Each
exporter should be able to be enabled or disabled independently through exporter should be able to be enabled or disabled independently through
Kolla-Ansible properties so if an exporter is found to have a significant Kolla Ansible properties so if an exporter is found to have a significant
detrimental impact it may be disabled. In order to help determine any potential detrimental impact it may be disabled. In order to help determine any potential
impact, Prometheus provides metrics for monitoring its own performance, and most impact, Prometheus provides metrics for monitoring its own performance, and most
exporters also include performance metrics for the exporters themselves. exporters also include performance metrics for the exporters themselves.
@ -318,7 +318,7 @@ maintaining, and exposing performance metrics. Some of the primary options are
discussed at [8]_. Another potential monitoring solution is Monasca which discussed at [8]_. Another potential monitoring solution is Monasca which
provides a centralized service for both tenant and control plane monitoring. provides a centralized service for both tenant and control plane monitoring.
Prometheus is more widely adopted and supported than many of the alternatives Prometheus is more widely adopted and supported than many of the alternatives
and has rich support for many of the tools already used in the Kolla-Ansible and has rich support for many of the tools already used in the Kolla Ansible
software stack. It's integration with Grafana provides an additional advantage software stack. It's integration with Grafana provides an additional advantage
over some of the alternate solutions. over some of the alternate solutions.
@ -335,14 +335,14 @@ Target Milestone for completion: Rocky 1
Work Items Work Items
---------- ----------
1. Prometheus server configuration for Kolla-Ansible 1. Prometheus server configuration for Kolla Ansible
2. Ansible deployment of existing Prometheus server container 2. Ansible deployment of existing Prometheus server container
3. Configuration of HAProxy to handle Prometheus server 3. Configuration of HAProxy to handle Prometheus server
4. Implement Kolla-Container Exporter 4. Implement Kolla-Container Exporter
5. kolla-ansible (or CLI) status command to display Kolla-Container Exporter 5. kolla-ansible (or CLI) status command to display Kolla-Container Exporter
results results
6. Integration with Grafana 6. Integration with Grafana
7. Implement Grafana dashboard(s) to provide visualization of Kolla-Ansible 7. Implement Grafana dashboard(s) to provide visualization of Kolla Ansible
cluster behavior cluster behavior
8. Exporters (see below) 8. Exporters (see below)