Update Documentation

Applying RST formatting conventions [1],[2] and [3]
[1] http://docs.openstack.org/contributor-guide/rst-conv/gen-guidelines.html
[2] http://docs.openstack.org/contributor-guide/rst-conv/inline-markups.html
[3] http://docs.openstack.org/contributor-guide/rst-conv/lists.html
Change-Id: I38b77a45d30ca0542058675dd1e8aba790c68567
Partially-implements: blueprint documentation-rework

1 files changed, 14 insertions, 14 deletions

diff --git a/doc/deployment-philosophy.rst b/doc/deployment-philosophy.rst
index 6a08e418f..87ed2195e 100644
--- a/doc/deployment-philosophy.rst
+++ b/doc/deployment-philosophy.rst
@@ -9,15 +9,15 @@ Overview
 
 Kolla has an objective to replace the inflexible, painful, resource intensive
 deployment process of OpenStack with a flexible, painless, inexpensive
-deployment process.  Often to deploy OpenStack at one-hundred node scale that
+deployment process. Often to deploy OpenStack at one-hundred node scale that
 a small business may require means building a team of OpenStack professionals
-to maintain and manage the OpenStack deployment.  Finding people experienced
+to maintain and manage the OpenStack deployment. Finding people experienced
 in OpenStack deployment is very difficult and expensive, resulting in a big
-barrier for OpenStack adoption.  Kolla seeks to remedy this set of problems by
+barrier for OpenStack adoption. Kolla seeks to remedy this set of problems by
 simplifying the deployment process but enabling flexible deployment models.
 
-Kolla is a highly opinionated deployment tool out of the box.  This permits
-Kolla to be deployable with configuration of three key/value pairs.  As an
+Kolla is a highly opinionated deployment tool out of the box. This permits
+Kolla to be deployable with configuration of three key/value pairs. As an
 operator's experience with OpenStack grows and the desire to customize
 OpenStack services increases, Kolla offers full capability to override every
 OpenStack service configuration option in the deployment.
@@ -27,12 +27,12 @@ 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
-a functional deployment.  If the Kolla upstream starts down the path of
+a functional deployment. If the Kolla upstream starts down the path of
 templating configuration options, the Ansible configuration could conceivably
 grow to hundreds of configuration key/value pairs which is unmanageable.
 Further, as new versions of Kolla are released, there would be independent
 customization available for different versions creating an unsupportable and
-difficult to document environment.  Finally, adding key/value pairs for
+difficult to document environment. Finally, adding key/value pairs for
 configuration options creates a situation in which a development and release
 cycle is required in order to successfully add a new customization.
 Essentially templating in configuration options is not a scalable solution
@@ -47,14 +47,14 @@ of existing deployment tools through a tidy simple design.
 
 During deployment of an OpenStack service, a basic set of default configuration
 options are merged with and overridden by custom ini configuration sections.
-Kolla deployment customization is that simple!  This does create a situation
+Kolla deployment customization is that simple! This does create a situation
 in which the Operator references the upstream documentation if a customization
-is desired in the OpenStack deployment.  Fortunately the configuration options
+is desired in the OpenStack deployment. Fortunately the configuration options
 documentation is extremely mature and well-formulated.
 
-As an example, consider running Kolla in a virtual machine.  In order to
+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
+to use the QEMU hypervisor, rather than the KVM hypervisor. To achieve this
 result, simply modify the file `/etc/kolla/config/nova/nova-compute.conf` and
 add the contents::
 
@@ -62,14 +62,14 @@ add the contents::
     virt_type=qemu
 
 After this change Kolla will use an emulated hypervisor with lower performance.
-Kolla could have templated this commonly modified configuration option.  If
+Kolla could have templated this commonly modified configuration option. If
 Kolla starts down this path, the Kolla project could end with hundreds of
 config options all of which would have to be subjectively evaluated for
 inclusion or exclusion in the source tree.
 
 Kolla's approach yields a solution which enables complete customization without
-any upstream maintenance burden.  Operators don't have to rely on a subjective
+any upstream maintenance burden. Operators don't have to rely on a subjective
 approval process for configuration options nor rely on a
-development/test/release cycle to obtain a desired customization.  Instead
+development/test/release cycle to obtain a desired customization. Instead
 operators have ultimate freedom to make desired deployment choices immediately
 without the approval of a third party.