Merge "Upgrade the rst convention of the Admin Guide"

doc/source/admin/advanced-configuration.rst

@@ -5,7 +5,7 @@ Advanced Configuration
 ======================
 
 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
@@ -24,56 +24,68 @@ The configuration parameters related to these options are:
 
 For the combined option, set the two variables below, while allowing the
 other two to accept their default values. In this configuration all REST
-API requests, internal and external, will flow over the same network. ::
+API requests, internal and external, will flow over the same network.
+
+.. code-block:: none
 
    kolla_internal_vip_address: "10.10.10.254"
    network_interface: "eth0"
 
+.. end
+
 For the separate option, set these four variables. In this configuration
 the internal and external REST API requests can flow over separate
-networks. ::
+networks.
+
+.. code-block:: none
 
    kolla_internal_vip_address: "10.10.10.254"
    network_interface: "eth0"
    kolla_external_vip_address: "10.10.20.254"
    kolla_external_vip_interface: "eth1"
 
+.. end
+
 Fully Qualified Domain Name Configuration
-=========================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 When addressing a server on the internet, it is more common to use
-a name, like www.example.net, instead of an address like 10.10.10.254.
+a name, like ``www.example.net``, instead of an address like
-If you prefer to use names to address the endpoints in your kolla
+``10.10.10.254``. If you prefer to use names to address the endpoints
-deployment use the variables:
+in your kolla deployment use the variables:
 
 - kolla_internal_fqdn
 - kolla_external_fqdn
 
-::
+.. code-block:: none
 
    kolla_internal_fqdn: inside.mykolla.example.net
    kolla_external_fqdn: mykolla.example.net
 
+.. end
+
 Provisions must be taken outside of kolla for these names to map to the
-configured IP addresses. Using a DNS server or the /etc/hosts file are
+configured IP addresses. Using a DNS server or the ``/etc/hosts`` file
-two ways to create this mapping.
+are two ways to create this mapping.
 
 RabbitMQ Hostname Resolution
-============================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-RabbitMQ doesn't work with IP address, hence the IP address of api_interface
+RabbitMQ doesn't work with IP address, hence the IP address of
-should be resolvable by hostnames to make sure that all RabbitMQ Cluster hosts
+``api_interface`` should be resolvable by hostnames to make sure that
-can resolve each others hostname beforehand.
+all RabbitMQ Cluster hosts can resolve each others hostname beforehand.
 
 TLS Configuration
-=================
+~~~~~~~~~~~~~~~~~
 
 An additional endpoint configuration option is to enable or disable
 TLS protection for the external VIP. TLS allows a client to authenticate
 the OpenStack service endpoint and allows for encryption of the requests
 and responses.
 
-.. note:: The kolla_internal_vip_address and kolla_external_vip_address must
+.. note::
+
+   The kolla_internal_vip_address and kolla_external_vip_address must
    be different to enable TLS on the external network.
 
 The configuration variables that control TLS networking are:
@@ -81,15 +93,18 @@ The configuration variables that control TLS networking are:
 - kolla_enable_tls_external
 - kolla_external_fqdn_cert
 
-The default for TLS is disabled; to enable TLS networking:
+The default for TLS is disabled, to enable TLS networking:
 
-::
+.. code-block:: none
 
    kolla_enable_tls_external: "yes"
    kolla_external_fqdn_cert: "{{ node_config_directory }}/certificates/mycert.pem"
 
+.. end
 
-.. note:: TLS authentication is based on certificates that have been
+.. note::
+
+   TLS authentication is based on certificates that have been
    signed by trusted Certificate Authorities. Examples of commercial
    CAs are Comodo, Symantec, GoDaddy, and GlobalSign. Letsencrypt.org
    is a CA that will provide trusted certificates at no charge. Many
@@ -97,8 +112,9 @@ The default for TLS is disabled; to enable TLS networking:
    company's domain. If using a trusted CA is not possible for your
    situation, you can use OpenSSL to create your own or see the section
    company's domain.  If using a trusted CA is not possible for your
-   situation, you can use `OpenSSL`_ to create your own or see the section
+   situation, you can use `OpenSSL <https://www.openssl.org>`__
-   below about kolla generated self-signed certificates.
+   to create your own or see the section below about kolla
+   generated self-signed certificates.
 
 Two certificate files are required to use TLS securely with authentication.
 These two files will be provided by your Certificate Authority. These
@@ -112,7 +128,7 @@ need to be distributed to the client.
 When using TLS to connect to a public endpoint, an OpenStack client will
 have settings similar to this:
 
-::
+.. code-block:: shell
 
    export OS_PROJECT_DOMAIN_ID=default
    export OS_USER_DOMAIN_ID=default
@@ -124,12 +140,14 @@ have settings similar to this:
    export OS_CACERT=/etc/pki/mykolla-cacert.crt
    export OS_IDENTITY_API_VERSION=3
 
-.. _OpenSSL: https://www.openssl.org/
+.. end
 
 Self-Signed Certificates
-========================
+~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. note:: Self-signed certificates should never be used in production.
+.. note::
+
+   Self-signed certificates should never be used in production.
 
 It is not always practical to get a certificate signed by a well-known
 trust CA, for example a development or internal test kolla deployment. In
@@ -139,7 +157,7 @@ For convenience, the ``kolla-ansible`` command will generate the necessary
 certificate files based on the information in the ``globals.yml``
 configuration file:
 
- ::
+.. code-block:: console
 
    kolla-ansible certificates
 
@@ -149,14 +167,16 @@ in the ``/etc/kolla/certificates/`` directory.
 .. _service-config:
 
 OpenStack Service Configuration in Kolla
-========================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. note:: As of now kolla only supports config overrides for ini based configs.
+.. note::
+
+   As of now kolla only supports config overrides for ini based configs.
 
 An operator can change the location where custom config files are read from by
 editing ``/etc/kolla/globals.yml`` and adding the following line.
 
-::
+.. code-block:: none
 
    # The directory to merge custom config files the kolla's config files
    node_custom_config: "/etc/kolla/config"
@@ -167,32 +187,41 @@ This can be done per-project, per-service or per-service-on-specified-host.
 For example to override scheduler_max_attempts in nova scheduler, the operator
 needs to create ``/etc/kolla/config/nova/nova-scheduler.conf`` with content:
 
-::
+.. path /etc/kolla/config/nova/nova-scheduler.conf
+.. code-block:: ini
 
    [DEFAULT]
    scheduler_max_attempts = 100
 
+.. end
+
 If the operator wants to configure compute node cpu and ram allocation ratio
 on host myhost, the operator needs to create file
 ``/etc/kolla/config/nova/myhost/nova.conf`` with content:
 
-::
+.. path /etc/kolla/config/nova/myhost/nova.conf
+.. code-block:: ini
 
    [DEFAULT]
    cpu_allocation_ratio = 16.0
    ram_allocation_ratio = 5.0
 
+.. end
+
 Kolla allows the operator to override configuration globally for all services.
 It will look for a file called ``/etc/kolla/config/global.conf``.
 
 For example to modify database pool size connection for all services, the
 operator needs to create ``/etc/kolla/config/global.conf`` with content:
 
-::
+.. path /etc/kolla/config/global.conf
+.. code-block:: ini
 
    [database]
    max_pool_size = 100
 
+.. end
+
 In case the operators want to customize ``policy.json`` file, they should
 create a full policy file for specific project in the same directory like above
 and Kolla will overwrite default policy file with it. Be aware, with some
@@ -204,72 +233,87 @@ For example to overwrite ``policy.json`` file of Neutron project, the operator
 needs to grab ``policy.json`` from Neutron project source code, update rules
 and then put it to ``/etc/kolla/config/neutron/policy.json``.
 
-.. note:: Currently kolla-ansible only support JSON format for policy file.
+.. note::
+
+   Currently kolla-ansible only support JSON format for policy file.
 
 The operator can make these changes after services were already deployed by
 using following command:
 
-::
+.. code-block:: console
 
    kolla-ansible reconfigure
 
+.. end
+
 IP Address Constrained Environments
-===================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If a development environment doesn't have a free IP address available for VIP
 configuration, the host's IP address may be used here by disabling HAProxy by
 adding:
 
-::
+.. code-block:: none
 
    enable_haproxy: "no"
 
+.. end
+
 Note this method is not recommended and generally not tested by the
 Kolla community, but included since sometimes a free IP is not available
 in a testing environment.
 
 External Elasticsearch/Kibana environment
-=========================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 It is possible to use an external Elasticsearch/Kibana environment. To do this
 first disable the deployment of the central logging.
 
-::
+.. code-block:: none
 
    enable_central_logging: "no"
 
+.. end
+
 Now you can use the parameter ``elasticsearch_address`` to configure the
 address of the external Elasticsearch environment.
 
 Non-default <service> port
-==========================
+~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 It is sometimes required to use a different than default port
-for service(s) in Kolla. It is possible with setting <service>_port
+for service(s) in Kolla. It is possible with setting
-in ``globals.yml`` file.
+``<service>_port`` in ``globals.yml`` file. For example:
-For example:
+
-::
+.. code-block:: none
 
    database_port: 3307
 
-As <service>_port value is saved in different services' configuration so
+.. end
+
+As ``<service>_port`` value is saved in different services' configuration so
 it's advised to make above change before deploying.
 
 Use an external Syslog server
-=============================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 By default, Fluentd is used as a syslog server to collect Swift and HAProxy
 logs. When Fluentd is disabled or you want to use an external syslog server,
-You can set syslog parameters in ``globals.yml`` file.
+You can set syslog parameters in ``globals.yml`` file. For example:
-For example:
+
-::
+.. code-block:: none
 
    syslog_server: "172.29.9.145"
    syslog_udp_port: "514"
 
-You can also set syslog facility names for Swift and HAProxy logs. By default,
+.. end
-Swift and HAProxy use ``local0`` and ``local1``, respectively.
+
-::
+You can also set syslog facility names for Swift and HAProxy logs.
+By default, Swift and HAProxy use ``local0`` and ``local1``, respectively.
+
+.. code-block:: none
 
    syslog_swift_facility: "local0"
    syslog_haproxy_facility: "local1"
+
+.. end

doc/source/admin/deployment-philosophy.rst

@@ -5,7 +5,7 @@ Kolla's Deployment Philosophy
 =============================
 
 Overview
-========
+~~~~~~~~
 
 Kolla has an objective to replace the inflexible, painful, resource-intensive
 deployment process of OpenStack with a flexible, painless, inexpensive
@@ -23,7 +23,7 @@ OpenStack services increases, Kolla offers full capability to override every
 OpenStack service configuration option in the deployment.
 
 Why not Template Customization?
-===============================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The Kolla upstream community does not want to place key/value pairs in the
 Ansible playbook configuration options that are not essential to obtaining
@@ -39,7 +39,7 @@ Essentially templating in configuration options is not a scalable solution
 and would result in an inability of the project to execute its mission.
 
 Kolla's Solution to Customization
-=================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Rather than deal with the customization madness of templating configuration
 options in Kolla's Ansible playbooks, Kolla eliminates all the inefficiencies
@@ -56,12 +56,17 @@ configuration options documentation is extremely mature and well-formulated.
 As an example, consider running Kolla in a virtual machine. In order to
 launch virtual machines from Nova in a virtual environment, it is necessary
 to use the QEMU hypervisor, rather than the KVM hypervisor. To achieve this
-result, simply `mkdir -p /etc/kolla/config` and modify the file
+result, simply :command:`mkdir -p /etc/kolla/config` and modify the file
-`/etc/kolla/config/nova.conf` with the contents::
+`/etc/kolla/config/nova.conf` with the contents
+
+.. path /etc/kolla/config/nova.conf
+.. code-block:: ini
 
    [libvirt]
    virt_type=qemu
 
+.. end
+
 After this change Kolla will use an emulated hypervisor with lower performance.
 Kolla could have templated this commonly modified configuration option. If
 Kolla starts down this path, the Kolla project could end with hundreds of

doc/source/admin/index.rst

@@ -1,8 +1,9 @@
+============
 Admin Guides
 ============
 
 .. toctree::
-   :maxdepth: 1
+   :maxdepth: 2
 
    advanced-configuration
    production-architecture-guide

doc/source/admin/production-architecture-guide.rst

@@ -9,7 +9,7 @@ meant to answer some questions regarding basic configuration options that Kolla
 requires. This document also contains other useful pointers.
 
 Node types and services running on them
-=======================================
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A basic Kolla inventory consists of several types of nodes, known in Ansible as
 ``groups``.
@@ -30,12 +30,12 @@ A basic Kolla inventory consists of several types of nodes, known in Ansible as
 * Monitoring - Monitor nodes which host monitoring services.
 
 Network configuration
-=====================
+~~~~~~~~~~~~~~~~~~~~~
 
 .. _interface-configuration:
 
 Interface configuration
-***********************
+-----------------------
 
 In Kolla operators should configure following network interfaces:
 
@@ -80,21 +80,21 @@ In Kolla operators should configure following network interfaces:
   with the bare metal cloud hosts in order to provide DHCP leases with
   PXE boot options. Defaults to ``network_interface``.
 
-.. WARNING::
+.. warning::
 
    Ansible facts does not recognize interface names containing dashes,
    in example ``br-ex`` or ``bond-0`` cannot be used because ansible will read
    them as ``br_ex`` and ``bond_0`` respectively.
 
 Docker configuration
-====================
+~~~~~~~~~~~~~~~~~~~~
 
 Because Docker is core dependency of Kolla, proper configuration of Docker can
 change the experience of Kolla significantly. Following section will highlight
 several Docker configuration details relevant to Kolla operators.
 
 Storage driver
-**************
+--------------
 
 In certain distributions Docker storage driver defaults to devicemapper, which
 can heavily hit performance of builds and deploys. We suggest to use btrfs or
@@ -102,14 +102,11 @@ aufs as driver. More details on which storage driver to use in
 `Docker documentation <https://docs.docker.com/engine/userguide/storagedriver/selectadriver/>`_.
 
 Volumes
-*******
+-------
 
 Kolla puts nearly all of persistent data in Docker volumes. These volumes are
-created in Docker working directory, which defaults to
+created in Docker working directory, which defaults to ``/var/lib/docker``
-
+directory.
-::
-
-    /var/lib/docker
 
 We recommend to ensure that this directory has enough space and is placed on
 fast disk as it will affect performance of builds, deploys as well as database