From 5db72659a062d45085227c237343a1c7a2687fe4 Mon Sep 17 00:00:00 2001 From: Piotr Parczewski Date: Mon, 18 Jan 2021 23:14:14 +0100 Subject: [PATCH] [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 --- README.rst | 20 +++--- .../roles/octavia-certificates/tasks/main.yml | 4 +- ansible/roles/octavia/defaults/main.yml | 2 +- deploy-guide/source/conf.py | 2 +- deploy-guide/source/index.rst | 2 +- .../admin/mariadb-backup-and-restore.rst | 4 +- doc/source/conf.py | 8 +-- doc/source/contributor/contributing.rst | 2 +- doc/source/index.rst | 10 +-- .../deployment-and-bootstrapping/bifrost.rst | 8 +-- .../central-logging-guide.rst | 2 +- .../logging-and-monitoring/monasca-guide.rst | 12 ++-- .../networking/neutron-extensions.rst | 2 +- doc/source/reference/networking/neutron.rst | 2 +- doc/source/reference/storage/swift-guide.rst | 2 +- doc/source/user/multinode.rst | 2 +- doc/source/user/quickstart.rst | 16 ++--- etc/kolla/globals.yml | 2 +- specs/prometheus.rst | 62 +++++++++---------- 19 files changed, 82 insertions(+), 82 deletions(-) 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)