[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

@@ -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
+Learn about Kolla Ansible by reading the documentation online
-`Kolla-Ansible <https://docs.openstack.org/kolla-ansible/latest/>`__.
+`Kolla Ansible <https://docs.openstack.org/kolla-ansible/latest/>`__.
 
 Get started by reading the `Developer
 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.
+   Kolla Ansible.
--  ``specs`` - Contains the Kolla-Ansible communities key arguments about
+-  ``specs`` - Contains the Kolla Ansible communities key arguments about
    architectural shifts in the code base.
 -  ``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

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

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

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'
 

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.

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.
 

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,
+     'doc-kolla-ansible.tex',
-     '%s Documentation' % project,
+     'Kolla Ansible Documentation',
      'OpenStack Foundation', 'manual'),
 ]
 

doc/source/contributor/contributing.rst

@@ -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>`_.

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
 <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
+previous release of Kolla Ansible, append the OpenStack release name to the
-example, to access Kolla Ansible documentation for the Stein release:
+URL. For example, to access documentation for the Stein release:
 https://docs.openstack.org/kolla-ansible/stein
 
 Release Notes

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:

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:

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
+* Your OpenStack deployment is *not* managed by Kolla Ansible, but you want
-  to take advantage of Monasca support in Kolla-Ansible.
+  to take advantage of Monasca support in Kolla Ansible.
-* Your OpenStack deployment *is* managed by Kolla-Ansible, but you do not
+* Your OpenStack deployment *is* managed by Kolla Ansible, but you do not
   want the Monasca deployment to share services with your OpenStack
   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.

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

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:
 

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

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

doc/source/user/quickstart.rst

@@ -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.
+``globals.yml`` is the main configuration file for Kolla Ansible.
-There are a few options that are required to deploy Kolla-Ansible:
+There are a few options that are required to deploy Kolla Ansible:
 
 * Image options
 
@@ -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,

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

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
+As with all optional services in Kolla Ansible, Prometheus deployment should be
-controlled by Kolla-Ansible variables.  A high level enable_prometheus variable
+controlled by Kolla Ansible variables.  A high level enable_prometheus variable
 should control whether Prometheus is used at all.  Additionally, additional
 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)