diff --git a/README.rst b/README.rst
index 49a3351847..14cb2848f1 100644
--- a/README.rst
+++ b/README.rst
@@ -1,5 +1,5 @@
=============
-Kolla-Ansible
+Kolla Ansible
=============
.. image:: https://governance.openstack.org/tc/badges/kolla-ansible.svg
@@ -8,9 +8,9 @@ Kolla-Ansible
.. 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.
Kolla's mission statement is:
@@ -28,8 +28,8 @@ configuration to suit the operator's exact requirements.
Getting Started
===============
-Learn about Kolla-Ansible by reading the documentation online
-`Kolla-Ansible `__.
+Learn about Kolla Ansible by reading the documentation online
+`Kolla Ansible `__.
Get started by reading the `Developer
Quickstart `__.
@@ -37,7 +37,7 @@ Quickstart `__
- `Barbican `__
@@ -81,7 +81,7 @@ Kolla-Ansible deploys containers for the following OpenStack projects:
Infrastructure components
-------------------------
-Kolla-Ansible deploys containers for the following infrastructure components:
+Kolla Ansible deploys containers for the following infrastructure components:
- `Collectd `__,
`Telegraf `__,
@@ -121,11 +121,11 @@ Directories
a working All-in-One (AIO) deployment.
- ``kolla_ansible`` - Contains password generation script.
- ``releasenotes`` - Contains releasenote of all features added in
- Kolla-Ansible.
-- ``specs`` - Contains the Kolla-Ansible communities key arguments about
+ Kolla Ansible.
+- ``specs`` - Contains the Kolla Ansible communities key arguments about
architectural shifts in the code base.
- ``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.
Getting Involved
diff --git a/ansible/roles/octavia-certificates/tasks/main.yml b/ansible/roles/octavia-certificates/tasks/main.yml
index 58ad6c9e55..ed58ec436c 100644
--- a/ansible/roles/octavia-certificates/tasks/main.yml
+++ b/ansible/roles/octavia-certificates/tasks/main.yml
@@ -1,10 +1,10 @@
---
# 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.
-# 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.
- name: Ensure server_ca and client_ca directories exist
diff --git a/ansible/roles/octavia/defaults/main.yml b/ansible/roles/octavia/defaults/main.yml
index ad3b9902ce..6972226490 100644
--- a/ansible/roles/octavia/defaults/main.yml
+++ b/ansible/roles/octavia/defaults/main.yml
@@ -165,7 +165,7 @@ octavia_amp_image_tag: "amphora"
# Load balancer topology options are [ SINGLE, ACTIVE_STANDBY ]
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`
# and keep your other Octavia config like before.
octavia_auto_configure: yes
diff --git a/deploy-guide/source/conf.py b/deploy-guide/source/conf.py
index 8dc09ad12f..9b9aae952c 100644
--- a/deploy-guide/source/conf.py
+++ b/deploy-guide/source/conf.py
@@ -54,7 +54,7 @@ source_suffix = '.rst'
master_doc = 'index'
# General information about the project.
-project = 'Kolla-Ansible'
+project = 'Kolla Ansible'
bug_tag = 'deploy-guide'
copyright = '2016, OpenStack contributors'
diff --git a/deploy-guide/source/index.rst b/deploy-guide/source/index.rst
index 640356251d..fded770e42 100644
--- a/deploy-guide/source/index.rst
+++ b/deploy-guide/source/index.rst
@@ -1,5 +1,5 @@
==============================
-Kolla-Ansible Deployment Guide
+Kolla Ansible Deployment Guide
==============================
Kolla provides Docker containers and Ansible playbooks to meet Kolla's mission.
diff --git a/doc/source/admin/mariadb-backup-and-restore.rst b/doc/source/admin/mariadb-backup-and-restore.rst
index 1c9d6a6ad9..bead7e58c2 100644
--- a/doc/source/admin/mariadb-backup-and-restore.rst
+++ b/doc/source/admin/mariadb-backup-and-restore.rst
@@ -4,7 +4,7 @@
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
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.
@@ -60,7 +60,7 @@ permissions defined during the configuration step; no password is required to
invoke these commands.
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
backups scheduled via a cron job.
diff --git a/doc/source/conf.py b/doc/source/conf.py
index bba9906a3f..f82455029f 100644
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -37,7 +37,7 @@ source_suffix = '.rst'
master_doc = 'index'
# General information about the project.
-project = 'kolla-ansible'
+project = 'Kolla Ansible'
copyright = '2013, OpenStack Foundation'
# 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.
-htmlhelp_basename = '%sdoc' % project
+htmlhelp_basename = 'kolla-ansibledoc'
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, documentclass
# [howto/manual]).
latex_documents = [
('index',
- 'doc-%s.tex' % project,
- '%s Documentation' % project,
+ 'doc-kolla-ansible.tex',
+ 'Kolla Ansible Documentation',
'OpenStack Foundation', 'manual'),
]
diff --git a/doc/source/contributor/contributing.rst b/doc/source/contributor/contributing.rst
index c4ede81de0..6fe56986b3 100644
--- a/doc/source/contributor/contributing.rst
+++ b/doc/source/contributor/contributing.rst
@@ -127,4 +127,4 @@ Project Team Lead Duties
~~~~~~~~~~~~~~~~~~~~~~~~
All common PTL duties are enumerated in the `PTL guide `_.
-Kolla-Ansible-specific PTL duties are listed in `Kolla Ansible PTL guide `_.
+Kolla Ansible-specific PTL duties are listed in `Kolla Ansible PTL guide `_.
diff --git a/doc/source/index.rst b/doc/source/index.rst
index ab4fdea073..602062f936 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -15,13 +15,13 @@
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
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
OpenStack quickly and as experience grows modify the OpenStack configuration to
suit the operator's exact requirements.
@@ -31,7 +31,7 @@ Related Projects
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
`_.
@@ -44,8 +44,8 @@ Site Notes
This documentation is continually updated and may not represent the state of
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
-example, to access Kolla Ansible documentation for the Stein release:
+previous release of Kolla Ansible, append the OpenStack release name to the
+URL. For example, to access documentation for the Stein release:
https://docs.openstack.org/kolla-ansible/stein
Release Notes
diff --git a/doc/source/reference/deployment-and-bootstrapping/bifrost.rst b/doc/source/reference/deployment-and-bootstrapping/bifrost.rst
index 6e8503de73..47b212d09a 100644
--- a/doc/source/reference/deployment-and-bootstrapping/bifrost.rst
+++ b/doc/source/reference/deployment-and-bootstrapping/bifrost.rst
@@ -159,7 +159,7 @@ Configure and Deploy a Bifrost Container
This section provides instructions for how to configure and deploy a container
running bifrost services.
-Prepare Kolla-Ansible Inventory
+Prepare Kolla Ansible Inventory
-------------------------------
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
host on which bifrost is deployed.
-Prepare Kolla-Ansible Configuration
+Prepare Kolla Ansible Configuration
-----------------------------------
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.
-Deploy Bifrost using Kolla-Ansible
+Deploy Bifrost using Kolla Ansible
----------------------------------
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
either using kolla-ansible or manually.
-By Kolla-Ansible
+By Kolla Ansible
----------------
For Development:
diff --git a/doc/source/reference/logging-and-monitoring/central-logging-guide.rst b/doc/source/reference/logging-and-monitoring/central-logging-guide.rst
index 183aeac1f6..f2a41ab76b 100644
--- a/doc/source/reference/logging-and-monitoring/central-logging-guide.rst
+++ b/doc/source/reference/logging-and-monitoring/central-logging-guide.rst
@@ -214,7 +214,7 @@ choosing *import* option.
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
configuration is split into four parts: Input, forwarding, filtering and
formatting. The following can be customised:
diff --git a/doc/source/reference/logging-and-monitoring/monasca-guide.rst b/doc/source/reference/logging-and-monitoring/monasca-guide.rst
index 8504302710..2644bf3b4b 100644
--- a/doc/source/reference/logging-and-monitoring/monasca-guide.rst
+++ b/doc/source/reference/logging-and-monitoring/monasca-guide.rst
@@ -49,19 +49,19 @@ following override in ``/etc/kolla/globals.yml``:
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,
MariaDB and Memcached. It can also include Keystone, but you will likely
want to integrate with the Keystone instance provided by your existing
OpenStack deployment. Some reasons to perform a standalone deployment are:
-* Your OpenStack deployment is *not* managed by Kolla-Ansible, but you want
- 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 *not* managed by Kolla Ansible, but you want
+ to take advantage of Monasca support in Kolla Ansible.
+* Your OpenStack deployment *is* managed by Kolla Ansible, but you do not
want the Monasca deployment to share services with your OpenStack
deployment. For example, in a combined deployment Monasca will share HAProxy
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
may have a dedicated monitoring and logging team, and wish to prevent that
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 |
+----------------------------------+-----------+--------------+--------------+---------+-----------+-----------------------------+
-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
be defined in the *external* `/etc/kolla/passwords.yml` file. For other
deployment methods you will need to consult the relevant documentation.
diff --git a/doc/source/reference/networking/neutron-extensions.rst b/doc/source/reference/networking/neutron-extensions.rst
index 33b9262811..389f848663 100644
--- a/doc/source/reference/networking/neutron-extensions.rst
+++ b/doc/source/reference/networking/neutron-extensions.rst
@@ -51,7 +51,7 @@ and versioning may differ depending on deploy configuration):
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
-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:
.. code-block:: console
diff --git a/doc/source/reference/networking/neutron.rst b/doc/source/reference/networking/neutron.rst
index 1b7d4d598e..7747956332 100644
--- a/doc/source/reference/networking/neutron.rst
+++ b/doc/source/reference/networking/neutron.rst
@@ -71,7 +71,7 @@ the following:
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.
To change this behaviour you need to set the following:
diff --git a/doc/source/reference/storage/swift-guide.rst b/doc/source/reference/storage/swift-guide.rst
index 022b8a814c..cf9a5d56c1 100644
--- a/doc/source/reference/storage/swift-guide.rst
+++ b/doc/source/reference/storage/swift-guide.rst
@@ -297,7 +297,7 @@ Enable Swift Recon in ``/etc/kolla/globals.yml``:
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
containers in existing deployments when running `kolla-ansible reconfigure`.
Instead we must use the `kolla-ansible upgrade` command, which will remove the
diff --git a/doc/source/user/multinode.rst b/doc/source/user/multinode.rst
index 00639fff51..8fc986a4ce 100644
--- a/doc/source/user/multinode.rst
+++ b/doc/source/user/multinode.rst
@@ -97,7 +97,7 @@ Edit the Inventory File
The ansible inventory file contains all the information needed to determine
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``.
Add the IP addresses or hostnames to a group and the services associated with
diff --git a/doc/source/user/quickstart.rst b/doc/source/user/quickstart.rst
index fd7498dada..4d12769f6b 100644
--- a/doc/source/user/quickstart.rst
+++ b/doc/source/user/quickstart.rst
@@ -11,7 +11,7 @@ Recommended reading
~~~~~~~~~~~~~~~~~~~
It's beneficial to learn basics of both `Ansible `__
-and `Docker `__ before running Kolla-Ansible.
+and `Docker `__ before running Kolla Ansible.
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
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
single node OpenStack on localhost. If you need to use separate host or more
than one node, edit ``multinode`` inventory:
@@ -351,8 +351,8 @@ For development, run:
Kolla globals.yml
-----------------
-``globals.yml`` is the main configuration file for Kolla-Ansible.
-There are a few options that are required to deploy Kolla-Ansible:
+``globals.yml`` is the main configuration file for Kolla Ansible.
+There are a few options that are required to deploy Kolla Ansible:
* Image options
@@ -399,7 +399,7 @@ There are a few options that are required to deploy Kolla-Ansible:
* 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.
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
- 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
``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
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 following assumes the use of the ``multinode`` inventory. If using a
@@ -554,7 +554,7 @@ Using OpenStack
./kolla-ansible post-deploy
. /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.
* For deployment or evaluation,
diff --git a/etc/kolla/globals.yml b/etc/kolla/globals.yml
index 2b014084a0..198cf87e90 100644
--- a/etc/kolla/globals.yml
+++ b/etc/kolla/globals.yml
@@ -718,7 +718,7 @@
##########################################
# 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`
# and keep your other Octavia config like before.
#octavia_auto_configure: yes
diff --git a/specs/prometheus.rst b/specs/prometheus.rst
index bb8719c0b3..ad0646b602 100644
--- a/specs/prometheus.rst
+++ b/specs/prometheus.rst
@@ -4,16 +4,16 @@ Prometheus Monitoring
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
-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.
Prometheus is a widely adopted and supported tool for monitoring, capable of
monitoring both system and service level characteristics. Many projects have
existing support for exporting data in Prometheus format either directly from
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
underlying software frameworks. There are also exporters to do system
performance monitoring which could provide further visibility into the health of
@@ -39,11 +39,11 @@ collected by Prometheus.
Use Cases
---------
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)
-2. Display dashboard illustrating overall system performance of Kolla-Ansible
+2. Display dashboard illustrating overall system performance of Kolla Ansible
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
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
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.
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
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
-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
scrape the data.
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
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
start with the exporters for which Kolla containers already exist. cAdvisor is
also recommended for early implementation since it provides more detailed
metrics for Docker container performance. We can investigate and add exporters
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.
Existing Kolla Containers
^^^^^^^^^^^^^^^^^^^^^^^^^
The following exporters already have associated Kolla containers (used in
Kolla-Kubernetes) and therefore should be minimal work to make available for a
-Kolla-Ansible deployment:
+Kolla Ansible deployment:
* HAProxy
* 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
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'
-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
that a simple Prometheus collector be implemented that exposes this data to
Prometheus.
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
-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
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.
@@ -148,7 +148,7 @@ the container with that name is in the indicated state).
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)``
* Number of containers in each state on each node: ``sum(kolla_containers) by
(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
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
-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
scrape duration which represents the performance characteristics of the
collector itself.
@@ -175,11 +175,11 @@ the standard Ansible deployment.
Running Prometheus
------------------
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
-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
deployment and analyzing problems that may occur during deployment, the
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
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
-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
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.
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
-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
interest and involvement in the project.
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
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
@@ -237,12 +237,12 @@ to be displayed will include:
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
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
of the cluster and should be identified.
* Other health statistics: on a normally running cluster, some basic 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
might indicate a problem). Other details can be added in the future as deemed
necessary.
@@ -257,8 +257,8 @@ left for a future blueprint.
Configuration
-------------
-As with all optional services in Kolla-Ansible, Prometheus deployment should be
-controlled by Kolla-Ansible variables. A high level enable_prometheus variable
+As with all optional services in Kolla Ansible, Prometheus deployment should be
+controlled by Kolla Ansible variables. A high level enable_prometheus variable
should control whether Prometheus is used at all. Additionally, additional
variables can be used to control individual exporters. For example,
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
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
impact, Prometheus provides metrics for monitoring its own performance, and most
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
provides a centralized service for both tenant and control plane monitoring.
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
over some of the alternate solutions.
@@ -335,14 +335,14 @@ Target Milestone for completion: Rocky 1
Work Items
----------
-1. Prometheus server configuration for Kolla-Ansible
+1. Prometheus server configuration for Kolla Ansible
2. Ansible deployment of existing Prometheus server container
3. Configuration of HAProxy to handle Prometheus server
4. Implement Kolla-Container Exporter
5. kolla-ansible (or CLI) status command to display Kolla-Container Exporter
results
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
8. Exporters (see below)