Fix docs rendering errors.

I was reading https://docs.openstack.org's version of the kolla-ansible
advanced configuration guide and noticed some RST rendering errors.
This patch corrects those errors so that the page renders correctly.

Change-Id: I330678d8971d286e67f115eace1cb606d30433b6

Author: mikalstill

doc/source/admin/advanced-configuration.rst

@@ -8,19 +8,21 @@ Endpoint Network Configuration
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 When an OpenStack cloud is deployed, the REST API of each service is presented
-as a series of endpoints. These endpoints are the admin URL, the internal
-URL, and the external URL.
+as a series of endpoints. These endpoints are the internal URL, and the
+external URL.
 
 Kolla offers two options for assigning these endpoints to network addresses:
-- Combined - Where all three endpoints share the same IP address
-- Separate - Where the external URL is assigned to an IP address that is
-different than the IP address shared by the internal and admin URLs
+
+* Combined - Where both endpoints share the same IP address
+* Separate - Where the external URL is assigned to an IP address that is
+  different than the IP address used by the internal URL
 
 The configuration parameters related to these options are:
-- kolla_internal_vip_address
-- network_interface
-- kolla_external_vip_address
-- kolla_external_vip_interface
+
+* kolla_internal_vip_address
+* network_interface
+* kolla_external_vip_address
+* kolla_external_vip_interface
 
 For the combined option, set the two variables below, while allowing the
 other two to accept their default values. In this configuration all REST
@@ -50,8 +52,8 @@ a name, like ``www.example.net``, instead of an address like
 ``10.10.10.254``. If you prefer to use names to address the endpoints
 in your kolla deployment use the variables:
 
-- kolla_internal_fqdn
-- kolla_external_fqdn
+* kolla_internal_fqdn
+* kolla_external_fqdn
 
 .. code-block:: yaml
 

doc/source/admin/tls.rst

@@ -80,10 +80,10 @@ TLS Configuration for internal/external VIP
 The configuration variables that control TLS for the internal and/or external
 VIP are:
 
-- ``kolla_enable_tls_external``
-- ``kolla_enable_tls_internal``
-- ``kolla_internal_fqdn_cert``
-- ``kolla_external_fqdn_cert``
+* ``kolla_enable_tls_external``
+* ``kolla_enable_tls_internal``
+* ``kolla_internal_fqdn_cert``
+* ``kolla_external_fqdn_cert``
 
 .. note::
 
@@ -224,11 +224,11 @@ Glance, Heat, Placement, Horizon, Barbican, and Cinder.
 The configuration variables that control back-end TLS for service endpoints
 are:
 
-- ``kolla_enable_tls_backend``
-- ``kolla_tls_backend_cert``
-- ``kolla_tls_backend_key``
-- ``haproxy_backend_cacert``
-- ``haproxy_backend_cacert_dir``
+* ``kolla_enable_tls_backend``
+* ``kolla_tls_backend_cert``
+* ``kolla_tls_backend_key``
+* ``haproxy_backend_cacert``
+* ``haproxy_backend_cacert_dir``
 
 The default state for back-end TLS is disabled. To enable TLS for the back-end
 communication:

doc/source/contributor/adding-a-new-service.rst

@@ -76,16 +76,16 @@ which Kolla uses throughout and which should be followed.
 
 Other than the above, most service roles abide by the following pattern:
 
-- ``Register``: Involves registering the service with Keystone, creating
+* ``Register``: Involves registering the service with Keystone, creating
   endpoints, roles, users, etc.
 
-- ``Config``: Distributes the config files to the nodes to be pulled into
+* ``Config``: Distributes the config files to the nodes to be pulled into
   the container on startup.
 
-- ``Bootstrap``: Creating the database (but not tables), database user for
+* ``Bootstrap``: Creating the database (but not tables), database user for
   the service, permissions, etc.
 
-- ``Bootstrap Service``: Starts a one shot container on the host to create
+* ``Bootstrap Service``: Starts a one shot container on the host to create
   the database tables, and other initial run time config.
 
 Ansible handlers are used to create or restart containers when necessary.

doc/source/contributor/release-notes.rst

@@ -9,17 +9,17 @@ Introduction
 
 Kolla Ansible (just like Kolla) uses the following release notes sections:
 
-- ``features`` --- for new features or functionality; these should ideally
+* ``features`` --- for new features or functionality; these should ideally
   refer to the blueprint being implemented;
-- ``fixes`` --- for fixes closing bugs; these must refer to the bug being
+* ``fixes`` --- for fixes closing bugs; these must refer to the bug being
   closed;
-- ``upgrade`` --- for notes relevant when upgrading from previous version;
+* ``upgrade`` --- for notes relevant when upgrading from previous version;
   these should ideally be added only between major versions; required when
   the proposed change affects behaviour in a non-backwards compatible way or
   generally changes something impactful;
-- ``deprecations`` --- to track deprecated features; relevant changes may
+* ``deprecations`` --- to track deprecated features; relevant changes may
   consist of only the commit message and the release note;
-- ``prelude`` --- filled in by the PTL before each release or RC.
+* ``prelude`` --- filled in by the PTL before each release or RC.
 
 Other release note types may be applied per common sense.
 Each change should include a release note unless being a ``TrivialFix``

doc/source/contributor/setup-identity-provider.rst

@@ -45,14 +45,14 @@ if you want to use any other realm name, you must to change 'new_realm' in the
 URIs used in the guide and replace the 'new_realm' with the realm name that you
 are using.
 
-- Access the admin console on http://localhost:8080/auth/ in the Administration Console option.
-- Authenticate using the credentials defined in the creation step.
-- Create a new realm in the http://localhost:8080/auth/admin/master/console/#/create/realm page.
-- After creating a realm, you will need to create a client to be used by Keystone; to do it, just access http://localhost:8080/auth/admin/master/console/#/create/client/new_realm.
-- To create a client, you will need to set the client_id (just choose anyone),
+* Access the admin console on http://localhost:8080/auth/ in the Administration Console option.
+* Authenticate using the credentials defined in the creation step.
+* Create a new realm in the http://localhost:8080/auth/admin/master/console/#/create/realm page.
+* After creating a realm, you will need to create a client to be used by Keystone; to do it, just access http://localhost:8080/auth/admin/master/console/#/create/client/new_realm.
+* To create a client, you will need to set the client_id (just choose anyone),
   the protocol (must be openid-connect) and the Root Url (you can leave it
   blank)
-- After creating the client, you will need to update some client's attributes
+* After creating the client, you will need to update some client's attributes
   like:
 
   - Enable the Implicit flow (this one allows you to use the OpenStack CLI with
@@ -72,12 +72,12 @@ are using.
       openstack-default-project            user attribute
       ==================================== ==============
 
-- After creating the client, you will need to create a user in that realm to
+* After creating the client, you will need to create a user in that realm to
   log in OpenStack via identity federation
-- To create a user, access http://localhost:8080/auth/admin/master/console/#/create/user/new_realm and fill the form with the user's data
-- After creating the user, you can access the tab "Credentials" to set the
+* To create a user, access http://localhost:8080/auth/admin/master/console/#/create/user/new_realm and fill the form with the user's data
+* After creating the user, you can access the tab "Credentials" to set the
   user's password
-- Then, in the tab "Attributes", you must set the authorization attributes to
+* Then, in the tab "Attributes", you must set the authorization attributes to
   be used by Keystone, these attributes are defined in the :ref:`attribute
   mapping <attribute_mapping>` in Keystone
 
@@ -90,10 +90,10 @@ Configuring Kolla Ansible to use the Identity Provider
 This section is about how one can get the data needed in
 :ref:`Setup OIDC via Kolla Ansible <setup-oidc-kolla-ansible>`.
 
-- name: The realm name, in this case it will be "new_realm"
-- identifier: http://localhost:8080/auth/realms/new_realm/ (again, the "new_realm" is the name of the realm)
-- certificate_file: This one can be downloaded from http://localhost:8080/auth/admin/master/console/#/realms/new_realm/keys
-- metadata_folder:
+* name: The realm name, in this case it will be "new_realm"
+* identifier: http://localhost:8080/auth/realms/new_realm/ (again, the "new_realm" is the name of the realm)
+* certificate_file: This one can be downloaded from http://localhost:8080/auth/admin/master/console/#/realms/new_realm/keys
+* metadata_folder:
 
   - localhost%3A8080%2Fauth%2Frealms%2Fnew_realm.client:
 

doc/source/reference/compute/libvirt-guide.rst

@@ -157,8 +157,8 @@ information:
 Kolla Ansible will search for these files for each compute node in the
 following locations and order on the host where Kolla Ansible is executed:
 
-- ``/etc/kolla/config/nova/nova-libvirt/<hostname>/``
-- ``/etc/kolla/config/nova/nova-libvirt/``
+* ``/etc/kolla/config/nova/nova-libvirt/<hostname>/``
+* ``/etc/kolla/config/nova/nova-libvirt/``
 
 In most cases you will want to have a unique set of server and client
 certificates and keys per hypervisor and with a common CA certificate. In this

doc/source/reference/compute/vmware-guide.rst

@@ -82,8 +82,8 @@ your NSX-T environment.
 It also hosts the API server that processes API calls.
 The NSX Manager interface provides two modes for configuring resources:
 
-- Policy mode
-- Manager mode
+* Policy mode
+* Manager mode
 
 In Kolla you will have the choice between both with neutron plugin
 vmware_nsxv3 for Manager mode and vmware_nsxp for Policy Mode.

doc/source/reference/logging-and-monitoring/central-logging-guide.rst

@@ -44,9 +44,9 @@ retention policy is applied to all indices which match the
 and then eventually deletes them. It can be customised via the following
 variables:
 
-- ``opensearch_apply_log_retention_policy``
-- ``opensearch_soft_retention_period_days``
-- ``opensearch_hard_retention_period_days``
+* ``opensearch_apply_log_retention_policy``
+* ``opensearch_soft_retention_period_days``
+* ``opensearch_hard_retention_period_days``
 
 By default the soft and hard retention periods are 30 and 60 days
 respectively. If you are upgrading from ElasticSearch, and have previously

doc/source/reference/logging-and-monitoring/prometheus-guide.rst

@@ -132,7 +132,7 @@ configure `ipmi_exporter <https://github.com/soundcloud/ipmi_exporter>`_, using
 the default value for ``node_custom_config``, you could create the following
 files:
 
-- ``/etc/kolla/config/prometheus/prometheus.yml.d/ipmi-exporter.yml``:
+* ``/etc/kolla/config/prometheus/prometheus.yml.d/ipmi-exporter.yml``:
 
   .. code-block:: jinja
 
@@ -171,7 +171,7 @@ files:
   where ``ipmi_exporter_listen_address`` is a variable containing the IP address of
   the node where the exporter is running.
 
--  ``/etc/kolla/config/prometheus/extras/file_sd/ipmi-exporter-targets.yml``:
+*  ``/etc/kolla/config/prometheus/extras/file_sd/ipmi-exporter-targets.yml``:
 
    .. code-block:: yaml
 

doc/source/reference/networking/designate-guide.rst

@@ -9,12 +9,12 @@ Overview
 
 Designate provides DNSaaS services for OpenStack:
 
--  REST API for domain/record management
--  Multi-tenant
--  Integrated with Keystone for authentication
--  Framework in place to integrate with Nova and Neutron
+*  REST API for domain/record management
+*  Multi-tenant
+*  Integrated with Keystone for authentication
+*  Framework in place to integrate with Nova and Neutron
    notifications (for auto-generated records)
--  Support for Bind9 and Infoblox out of the box
+*  Support for Bind9 and Infoblox out of the box
 
 Configuration on Kolla deployment
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~