Remove latinisms and future tense

bug: #1216118

Change-Id: I6943d846556a490f8ff093b6eedffb4694af9c16
author: diane fleming

doc/src/docbkx/openstack-compute-admin/aboutcompute.xml

@@ -58,7 +58,7 @@
             </listitem>
             <listitem>
                 <para><link xlink:href="https://wiki.openstack.org/wiki/GeneralBareMetalProvisioningFramework">
-                        Bare Metal</link> - Provisions physical hardware via pluggable sub-drivers.</para>
+                        Bare Metal</link> - Provisions physical hardware through pluggable sub-drivers.</para>
             </listitem>
         </itemizedlist>
     </section>
@@ -71,9 +71,9 @@
             by the system administrator editing the appropriate <filename>policy.json</filename>
             file that maintains the rules. For example, a rule can be defined so that a user cannot
             allocate a public IP without the admin role. A user's access to particular images is
-            limited by tenant, but the username and password are assigned per user. Key pairs
-            granting access to an instance are enabled per user, but quotas to control resource
-            consumption across available hardware resources are per tenant. <note>
+            limited by tenant, but the username and password are assigned for each user. Key pairs
+            granting access to an instance are enabled for each user, but quotas to control resource
+            consumption across available hardware resources are for each tenant. <note>
                 <para>Earlier versions of OpenStack used the term "project" instead of "tenant".
                     Because of this legacy terminology, some command-line tools use
                         <literal>--project_id</literal> when a tenant ID is expected.</para>
@@ -194,13 +194,13 @@
      </figure>
 
             <para>The OpenStack system copies the base image from the
-                image store to local disk which is used as the first
-                disk of the instance (vda), having small images will
-                result in faster start up of your instances as less
+                image store to local disk, which is used as the first
+                disk of the instance (vda). Using small images 
+                results in faster start up of your instances as less
                 data needs to be copied across the network. The system
                 also creates a new empty disk image to present as the
                 second disk (vdb). Be aware that the second disk is an
-                empty disk with an emphemeral life as it is destroyed
+                empty disk with an ephemeral life as it is destroyed
                 when you delete the instance. The compute node
                 attaches to the requested <systemitem class="service">cinder-volume</systemitem> using iSCSI and
                 maps this to the third disk (vdc) as requested. The
@@ -252,8 +252,8 @@
             scheduler selects the most suitable compute controller to host an instance.</para><para>OpenStack Compute is built on a shared-nothing, messaging-based architecture. You can run all
             of the major components on multiple servers including a compute controller, volume
             controller, network controller, and object store (or image service). A cloud controller
-            communicates with the internal object store via HTTP (Hyper Text Transfer Protocol), but
-            it communicates with a scheduler, network controller, and volume controller via AMQP
+            communicates with the internal object store through HTTP (Hyper Text Transfer Protocol), but
+            it communicates with a scheduler, network controller, and volume controller through AMQP
             (Advanced Message Queue Protocol). To avoid blocking each component while waiting for a
             response, OpenStack Compute uses asynchronous calls, with a call-back that gets
             triggered when a response is received.</para>
@@ -264,25 +264,22 @@
 
       <para>OpenStack provides two classes of block storage,
       "ephemeral" storage and persistent "volumes".  Ephemeral storage
-      exists only for the life of an instance, it will persist across
-      reboots of the guest operating system but when the instance is
+      exists only for the life of an instance. It persists across
+      reboots of the guest operating system, but when the instance is
       deleted so is the associated storage.  All instances have some
       ephemeral storage.  Volumes are persistent virtualized block
       devices independent of any particular instance.  Volumes may be
       attached to a single instance at a time, but may be detached or
       reattached to a different instance while retaining all data,
       much like a USB drive.</para>
-
       <simplesect xml:id="about-ephemeral-storage">
 	<title>Ephemeral Storage</title>
-
 	<para>Ephemeral storage is associated with a single unique
-	instance.  Its size is defined by the flavor of the
+	instance. Its size is defined by the flavor of the
 	instance.</para>
-
 	<para>Data on ephemeral storage ceases to exist when the
        instance it is associated with is terminated. Rebooting the
-       VM or restarting the host server, however, will not destroy
+       VM or restarting the host server, however, does not destroy
        ephemeral data. In the typical use case an instance's root
        filesystem is stored on ephemeral storage. This is often an
        unpleasant surprise for people unfamiliar with the cloud model
@@ -296,7 +293,7 @@
 	table or filesystem.  Cloud aware operating system images may
 	discover, format, and mount this device.  For example the
 	cloud-init package included in Ubuntu's stock cloud images
-	will format this space as an ext3 filesystem and mount it on
+ format this space as an ext3 filesystem and mount it on
 	/mnt. It is important to note this a feature of the guest
 	operating system. OpenStack only provisions the raw
 	storage.</para>
@@ -318,20 +315,19 @@
 	Volumes may attached to only one instance at a time, but may
 	be detached and reattached to either the same or different
 	instances.</para>
-
 	<para>It is possible to configure a volume so that it is bootable and
                 provides a persistent virtual instance similar to
                 traditional non-cloud based virtualization systems. In
                 this use case the resulting instance may still have
                 ephemeral storage depending on the flavor selected,
-                but the root filesystem (and possibly others) will be
-                on the persistent volume and thus state will be
-                maintained even if the instance it shutdown. Details
+                but the root filesystem (and possibly others) is
+                on the persistent volume and its state is
+                maintained even if the instance it shut down. Details
                 of this configuration are discussed in the <link xlink:href="http://docs.openstack.org/cli/quick-start/content/"><citetitle>OpenStack Clients Guide</citetitle></link>.</para>
           <para>Volumes do not provide concurrent access from multiple
 	instances.  For that you need either a traditional network
 	filesystem like NFS or CIFS or a cluster filesystem such as
-	GlusterFS.  These may be built within an OpenStack cluster or
+	GlusterFS. These may be built within an OpenStack cluster or
 	provisioned outside of it, but are not features provided by
 	the OpenStack software.</para>
       </simplesect>

doc/src/docbkx/openstack-compute-admin/aboutimages.xml

@@ -32,7 +32,7 @@
 
             <listitem><para>S3 - This backend allows OpenStack Image Service to store virtual machine images in Amazon’s S3 service.</para></listitem>
 
-            <listitem><para>HTTP - OpenStack Image Service can read virtual machine images that are available via HTTP somewhere on the Internet. This store is readonly.</para></listitem></itemizedlist>
+            <listitem><para>HTTP - OpenStack Image Service can read virtual machine images that are available through HTTP somewhere on the Internet. This store is readonly.</para></listitem></itemizedlist>
             </section>
 
             <section xml:id="openstack-imaging-service-registry-servers">

doc/src/docbkx/openstack-compute-admin/adding-images.xml

@@ -33,7 +33,7 @@
       these properties.</para>
 
     <para><parameter>architecture</parameter>: The CPU architecture
-      that must be supported by the hypervisor, e.g.
+      that must be supported by the hypervisor, such as,
         <literal>x86_64</literal>, <literal>arm</literal>,
         <literal>ppc64</literal>. Run <command>uname -m</command> to
       get the architecture of a machine. We strongly recommend using
@@ -275,7 +275,7 @@
                 <term>auto_disk_config</term>
                 <listitem>
                   <para>A boolean option. If true, the root partition
-                    on the disk will be automatically resized before
+                    on the disk is automatically resized before
                     the instance boots. This value is only taken into
                     account by the Compute service when using a
                     Xen-based hypervisor with the XenAPI driver. The

doc/src/docbkx/openstack-compute-admin/ch_identity_mgmt.xml

@@ -45,7 +45,7 @@
         <literal>user_crud_extension</literal> filter, insert it after
       the <literal>*_body</literal> middleware and before the
         <literal>public_service</literal> app in the public_api WSGI
-      pipeline in <filename>keystone-paste.ini</filename> e.g.:</para>
+      pipeline in <filename>keystone-paste.ini</filename>. For example:</para>
     <screen><computeroutput>[filter:user_crud_extension]
 paste.filter_factory = keystone.contrib.user_crud:CrudExtension.factory
 
@@ -166,7 +166,7 @@ pipeline = [...] json_body stats_reporting ec2_extension [...] admin_service</co
     <para>Generally, the following is the first step after a source
       installation:</para>
     <screen><prompt>$</prompt> <userinput>keystone-manage db_sync</userinput></screen>
-    <para>Invoking keystone-manage by itself will give you additional
+    <para>Invoking <command>keystone-manage</command> by itself gives you additional
       usage information.</para>
   </section>
   <section xml:id="configuring-services-to-work-with-keystone">
@@ -191,7 +191,7 @@ pipeline = [...] json_body stats_reporting ec2_extension [...] admin_service</co
         </para>
       </listitem>
     </itemizedlist>
-    <para>The middleware will pass those data down to the service as
+    <para>The middleware passes data to the service as
       headers.</para>
 <xi:include href="../common/section_cli_keystone_credentials.xml"/>
 <xi:include href="../common/section_cli_keystone_apiv3.xml"/>
@@ -438,10 +438,10 @@ role_tree_dn = ou=Roles,dc=openstack,dc=org</computeroutput>
 user_id_attribute = uidNumber
 user_name_attribute = cn</computeroutput>
 </screen>
-        <para>There is a set of allowed actions per object type that
-          you can modify depending on your specific deployment. For
-          example, the users are managed by another tool and you have
-          only read access, in such case the configuration is:</para>
+        <para>Depending on your specific deployment,
+          you can modify a set of allowed actions for each object type. For
+          example, when users are managed by another tool and you have
+          only read access, the configuration is:</para>
         <screen><computeroutput>[ldap]
 
 user_allow_create = False
@@ -457,17 +457,17 @@ role_allow_update = True
 role_allow_delete = True</computeroutput>
 </screen>
         <para>There are some configuration options for filtering
-          users, tenants and roles, if the backend is providing too
-          much output, in such case the configuration will look like:</para>
+          users, tenants and roles, if the backend provides too 
+          much output, the configuration looks as follows:</para>
         <screen><computeroutput>[ldap]
 user_filter = (memberof=CN=openstack-users,OU=workgroups,DC=openstack,DC=com)
 tenant_filter =
 role_filter =</computeroutput>
 </screen>
-        <para>In case that the directory server does not have an
-          attribute enabled of type boolean for the user, there are
-          several configuration parameters that can be used to extract
-          the value from an integer attribute like in Active
+        <para>If the directory server does not have an
+          attribute enabled of type boolean for the user, you can use
+          several configuration parameters to extract
+          the value from an integer attribute, like in Active
           Directory:</para>
         <screen><computeroutput>[ldap]
 user_enabled_attribute = userAccountControl
@@ -529,7 +529,7 @@ role_attribute_ignore    =</computeroutput></screen>
           middleware using the 'admin_user' and 'admin_password'
           options. When using the 'admin_user' and 'admin_password'
           options the 'admin_token' parameter is optional. If
-          'admin_token' is specified it will by used only if the
+          'admin_token' is specified, it is used only if the
           specified token is still valid.</para>
         <para>Here is an example paste config filter that makes use
           of the 'admin_user' and 'admin_password' parameters:</para>