[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
parent
01c0c39fb0
commit
5db72659a0
20
README.rst
20
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 <https://docs.openstack.org/kolla-ansible/latest/>`__.
|
||||
Learn about Kolla Ansible by reading the documentation online
|
||||
`Kolla Ansible <https://docs.openstack.org/kolla-ansible/latest/>`__.
|
||||
|
||||
Get started by reading the `Developer
|
||||
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
|
||||
------------------
|
||||
|
||||
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/>`__
|
||||
- `Barbican <https://docs.openstack.org/barbican/latest/>`__
|
||||
|
|
@ -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 <https://collectd.org/>`__,
|
||||
`Telegraf <https://docs.influxdata.com/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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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'
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
==============================
|
||||
Kolla-Ansible Deployment Guide
|
||||
Kolla Ansible Deployment Guide
|
||||
==============================
|
||||
|
||||
Kolla provides Docker containers and Ansible playbooks to meet Kolla's mission.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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'),
|
||||
]
|
||||
|
||||
|
|
|
|||
|
|
@ -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>`_.
|
||||
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>`_.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
<https://docs.openstack.org/kolla/latest/>`_.
|
||||
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Recommended reading
|
|||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
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
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -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,
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue