Arch Design edits

Many minor edits:
Improve markup, follow conventions, add glossary items, fix
capitalization,...

Change-Id: I85693ef2d2c617327c707d13ffd5f05b4d97d1d7

doc/arch-design/ch_hybrid.xml

@@ -60,7 +60,8 @@
         launches a public cloud instance.</para>
     <para>There are commercially available options, such as
         Rightscale, and open source options, such as ManageIQ
-        (http://manageiq.org/), but there is no single CMP that can
+        (<link xlink:href="http://manageiq.org/">http://manageiq.org</link>),
+        but there is no single CMP that can
         address all needs in all scenarios. Whereas most of the
         sections of this book talk about the aspects of OpenStack, an
         architect needs to consider when designing an OpenStack

doc/arch-design/compute_focus/section_architecture_compute_focus.xml

@@ -442,7 +442,7 @@
         <para>Ensure that the design can accommodate the regular
           periodic installation of application security patches while
           maintaining the required workloads. The frequency of security
-          patches for the proposed OS - hypervisor combination will have an
+          patches for the proposed OS-hypervisor combination will have an
           impact on performance and the patch installation process could
           affect maintenance windows.</para>
       </listitem>

doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml

@@ -376,7 +376,8 @@
     <para>Also consider several specialized components:</para>
     <itemizedlist>
         <listitem>
-            <para>Orchestration module (heat)</para>
+            <para><glossterm>Orchestration</glossterm> module
+            (<glossterm>heat</glossterm>)</para>
         </listitem>
     </itemizedlist>
     <para>It is safe to assume that, given the nature of the

doc/arch-design/generalpurpose/section_architecture_general_purpose.xml

@@ -730,7 +730,8 @@
         certain components that will always be present, (Compute and
         Image Service, for example) there are other services that may not be
         required. As an example, a certain design might not need
-        Orchestration. Omitting Orchestration would not have a significant
+        <glossterm>Orchestration</glossterm>. Omitting
+        Orchestration would not have a significant
         impact on the overall design of a cloud; however, if the
         architecture uses a replacement for OpenStack Object Storage for its
         storage component, it could potentially have significant

doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml

@@ -89,7 +89,9 @@
     <para>There is also a potential to leverage the Orchestration and
         Telemetry modules to provide an auto-scaling,
         orchestrated web application environment. Defining the web
-        applications in Heat Orchestration Templates (HOT) would
+        applications in <glossterm
+        baseform="Heat Orchestration Template (HOT)">Heat Orchestration Templates (HOT)</glossterm>
+        would
         negate the reliance on the scripted Puppet solution currently
         employed.</para>
     <para>OpenStack Networking can be used to control hardware load

doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml

@@ -131,7 +131,7 @@
         cloud, the next design choice which will affect your design is
         the choice of network service which will be used to service
         instances in the cloud. The choice between legacy networking (nova-network), as a
-        part of OpenStack Compute Service, and OpenStack Networking
+        part of OpenStack Compute, and OpenStack Networking
         (neutron), has tremendous implications and will have
         a huge impact on the architecture and design of the cloud
         network infrastructure.</para>
@@ -313,7 +313,7 @@
         the distribution vendor's OpenStack packages might be a
         requirement for support).</para>
     <para>OS selection also directly influences hypervisor selection.
-        A cloud architect who selects Ubuntu or RHEL has some
+        A cloud architect who selects Ubuntu, RHEL, or SLES has some
         flexibility in hypervisor; KVM, Xen, and LXC are supported
         virtualization methods available under OpenStack Compute
         (nova) on these Linux distributions. A cloud architect who
@@ -321,25 +321,35 @@
         Server. Similarly, a cloud architect who selects XenServer is
         limited to the CentOS-based dom0 operating system provided
         with XenServer.</para>
-    <para>The primary factors that play into OS/hypervisor selection
+    <para>The primary factors that play into OS-hypervisor selection
         include:</para>
-    <itemizedlist>
+    <variablelist>
+        <varlistentry>
+          <term>User requirements</term>
           <listitem>
-            <para>User requirements: The selection of OS/hypervisor
+            <para>The selection of OS-hypervisor
                 combination first and foremost needs to support the
                 user requirements.</para>
           </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term>Support</term>
           <listitem>
-            <para>Support: The selected OS/hypervisor combination
+            <para>The selected OS-hypervisor combination
                 needs to be supported by OpenStack.</para>
           </listitem>
+        </varlistentry>
+        <varlistentry>
+          <term>Interoperability</term>
           <listitem>
-            <para>Interoperability: The OS/hypervisor needs to be
+            <para>The OS-hypervisor needs to be
                 interoperable with other features and services in the
                 OpenStack design in order to meet the user
                 requirements.</para>
           </listitem>
-    </itemizedlist></section>
+        </varlistentry>
+    </variablelist>
+    </section>
     <section xml:id="hypervisor-tech-considerations">
       <title>Hypervisor</title>
     <para>OpenStack supports a wide variety of hypervisors, one or
@@ -347,7 +357,7 @@
         include:</para>
     <itemizedlist>
         <listitem>
-            <para>KVM (and Qemu)</para>
+            <para>KVM (and QEMU)</para>
         </listitem>
         <listitem>
             <para>XCP/XenServer</para>
@@ -408,29 +418,38 @@
         in a general purpose cloud are:</para>
     <itemizedlist>
         <listitem>
-            <para>OpenStack Compute (nova)</para>
+            <para>OpenStack <glossterm>Compute</glossterm>
+            (<glossterm>nova</glossterm>)</para>
         </listitem>
         <listitem>
-            <para>OpenStack Networking (neutron)</para>
+            <para>OpenStack <glossterm>Networking</glossterm>
+            (<glossterm>neutron</glossterm>)</para>
         </listitem>
         <listitem>
-            <para>OpenStack Image Service (glance)</para>
+            <para>OpenStack <glossterm>Image Service</glossterm>
+            (<glossterm>glance</glossterm>)</para>
         </listitem>
         <listitem>
-            <para>OpenStack Identity (keystone)</para>
+            <para>OpenStack <glossterm>Identity</glossterm>
+            (<glossterm>keystone</glossterm>)</para>
         </listitem>
         <listitem>
-            <para>OpenStack dashboard (horizon)</para>
+            <para>OpenStack <glossterm>dashboard</glossterm>
+            (<glossterm>horizon</glossterm>)</para>
         </listitem>
         <listitem>
-            <para>Telemetry module (ceilometer)</para>
+            <para><glossterm>Telemetry</glossterm> module
+            (<glossterm>ceilometer</glossterm>)</para>
         </listitem>
     </itemizedlist>
-    <para>A general purpose cloud may also include OpenStack Object
+    <para>A general purpose cloud may also include OpenStack
-        Storage (swift). OpenStack Block Storage (cinder) may be
+        <glossterm>Object Storage</glossterm> (<glossterm>swift</glossterm>).
+        OpenStack <glossterm>Block Storage</glossterm>
+        (<glossterm>cinder</glossterm>) may be
         selected to provide persistent storage to applications and
         instances although, depending on the use case, this could be
-        optional.</para></section>
+        optional.</para>
+    </section>
     <section xml:id="supplemental-software-tech-considerations">
       <title>Supplemental software</title>
     <para>A general purpose OpenStack deployment consists of more than
@@ -455,7 +474,7 @@
         implementations are also made highly available. This high
         availability can be achieved by using software such as
         Keepalived or Pacemaker with Corosync. Pacemaker and Corosync
-        can provide Active-Active or Active-Passive highly available
+        can provide active-active or active-passive highly available
         configuration depending on the specific service in the
         OpenStack environment. Using this software can affect the
         design as it assumes at least a 2-node controller

doc/arch-design/generalpurpose/section_user_requirements_general_purpose.xml

@@ -7,12 +7,13 @@
     <?dbhtml stop-chunking?>
     <title>User requirements</title>
     <para>The general purpose cloud is built following the
-        Infrastructure-as-a-Service (IaaS) model; as a platform best
+        <glossterm baseform="IaaS">Infrastructure-as-a-Service (IaaS)</glossterm>
+        model; as a platform best
         suited for use cases with simple requirements. The general
         purpose cloud user requirements themselves are typically not
         complex. However, it is still important to capture them even
         if the project has minimum business and technical requirements
-        such as a Proof of Concept (PoC) or a small lab
+        such as a proof of concept (PoC) or a small lab
         platform.</para>
     <para>These user considerations are written from the perspective
         of the organization that is building the cloud, not from the

doc/arch-design/introduction/section_how_this_book_is_organized.xml

@@ -7,7 +7,8 @@
     <title>How this book is organized</title>
     <para>This book has been organized into various chapters that help
         define the use cases associated with making architectural
-        choices related to an OpenStack cloud installation. Each
+        choices related to an <glossterm>OpenStack</glossterm> cloud
+        installation. Each
         chapter is intended to stand alone to encourage individual
         chapter readability, however each chapter is designed to
         contain useful information that may be applicable in