s/Image Service/Image service/g

Follow conventions for capitalization.

Change-Id: I101efe345710363fa661840227886dc028efb090

doc/openstack-ops/app_usecases.xml

@@ -46,7 +46,7 @@
       <glossterm>cell</glossterm>s in an OpenStack Compute cells setup. Some
       sites span multiple data centers, some use off compute node storage with
       a shared file system, and some use on compute node storage with a
-      non-shared file system. Each site deploys the Image Service with an
+      non-shared file system. Each site deploys the Image service with an
       Object Storage back end. A central Identity Service, dashboard, and
       Compute API service are used. A login to the dashboard triggers a SAML
       login with Shibboleth, which creates an <glossterm>account</glossterm>
@@ -265,7 +265,7 @@
       are ongoing with Hyper-V on Windows Server 2008.</para>
 
       <para>We use the Puppet Labs OpenStack modules to configure Compute,
-      Image Service, Identity, and dashboard. Puppet is used widely for
+      Image service, Identity, and dashboard. Puppet is used widely for
       instance configuration, and Foreman is used as a GUI for reporting and
       instance provisioning.</para>
 

doc/openstack-ops/ch_arch_cloud_controller.xml

@@ -156,7 +156,7 @@
     </listitem>
 
     <listitem>
-      <para>Image Service for the image management</para>
+      <para>Image service for the image management</para>
     </listitem>
   </itemizedlist>
 
@@ -584,7 +584,7 @@
   <section xml:id="images">
     <title>Images</title>
 
-    <para>The OpenStack Image Service consists of two parts:
+    <para>The OpenStack Image service consists of two parts:
     <code>glance-api</code> and <code>glance-registry</code>. The former is
     responsible for the delivery of images; the compute node uses it to
     download images from the backend. The latter maintains the metadata
@@ -600,9 +600,9 @@
       </indexterm><indexterm class="singular">
         <primary>metadata</primary>
 
-        <secondary>OpenStack Image Service and</secondary>
+        <secondary>OpenStack Image service and</secondary>
       </indexterm><indexterm class="singular">
-        <primary>Image Service</primary>
+        <primary>Image service</primary>
 
         <secondary>design considerations</secondary>
       </indexterm><indexterm class="singular">

doc/openstack-ops/ch_ops_backup_recovery.xml

@@ -159,7 +159,7 @@ find $backup_dir -ctime +7 -type f -delete</programlisting>
 
       <para><code>/etc/glance</code> and <code>/var/log/glance</code> follow
       the same rules as their nova counterparts.<indexterm class="singular">
-          <primary>Image Service</primary>
+          <primary>Image service</primary>
 
           <secondary>backup/recovery of</secondary>
         </indexterm></para>

doc/openstack-ops/ch_ops_customize.xml

@@ -229,7 +229,7 @@ stable/havana devstack/</userinput></screen></para>
     <para>Now that you have an OpenStack development environment, you're free
     to hack around without worrying about damaging your production deployment.
     <xref linkend="localrc" /> provides a working environment for running
-    OpenStack Identity, Compute, Block Storage, Image Service, the OpenStack
+    OpenStack Identity, Compute, Block Storage, Image service, the OpenStack
     dashboard, and Object Storage with the stable/havana branches as the
     starting point.</para>
 
@@ -252,7 +252,7 @@ NOVA_BRANCH=stable/havana
 # OpenStack Block Storage branch
 CINDER_BRANCH=stable/havana
 
-# OpenStack Image Service branch
+# OpenStack Image service branch
 GLANCE_BRANCH=stable/havana
 
 # OpenStack Dashboard branch

doc/openstack-ops/ch_ops_lay_of_land.xml

@@ -20,7 +20,7 @@
     <para>As a cloud administrative user, you can use the OpenStack dashboard
     to create and manage projects, users, images, and flavors. Users are
     allowed to create and manage images within specified projects and to share
-    images, depending on the Image Service configuration. Typically, the
+    images, depending on the Image service configuration. Typically, the
     policy configuration allows admin users only to set quotas and create and
     manage services. The dashboard provides an <guilabel>Admin</guilabel> tab
     with a <guilabel>System Panel</guilabel> and <guilabel>Identity

doc/openstack-ops/ch_ops_log_monitor.xml

@@ -802,7 +802,7 @@ notification_driver=messagingv2</programlisting>
 
       <para>Intelligent alerting can be thought of as a form of continuous
       integration for operations. For example, you can easily check to see
-      whether the Image Service is up and running by ensuring that
+      whether the Image service is up and running by ensuring that
       the&#160;<code>glance-api</code> and <code>glance-registry</code>
       processes are running or by seeing whether <code>glace-api</code> is
       responding on port 9292.<indexterm class="singular">
@@ -824,7 +824,7 @@ notification_driver=messagingv2</programlisting>
         </indexterm></para>
 
       <para>But how can you tell whether images are being successfully
-      uploaded to the Image Service? Maybe the disk that Image Service is
+      uploaded to the Image service? Maybe the disk that Image service is
       storing the images on is full or the S3 backend is down. You could
       naturally check this by doing a quick image upload:</para>
 

doc/openstack-ops/ch_ops_projects_users.xml

@@ -185,7 +185,7 @@
       were to set an Image quota limit of 5 GB, then all projects in your
       cloud will be able to store only 5 GB of images and snapshots.<indexterm
           class="singular">
-          <primary>Image Service</primary>
+          <primary>Image service</primary>
 
           <secondary>quota setting</secondary>
         </indexterm></para>

doc/openstack-ops/ch_ops_upgrades.xml

@@ -221,7 +221,7 @@
       </listitem>
 
       <listitem>
-        <para>Upgrade the OpenStack Image Service (glance).</para>
+        <para>Upgrade the OpenStack Image service (glance).</para>
       </listitem>
 
       <listitem>
@@ -332,7 +332,7 @@ scheduler=havana</programlisting>
           Installation Guide</citetitle></link> and upgrading to the
       same architecture for Havana. All nodes should run Ubuntu 12.04
       LTS. This section primarily addresses upgrading core OpenStack
-      services, such as the Identity Service (keystone), Image Service
+      services, such as the Identity Service (keystone), Image service
       (glance), Compute (nova) including networking, Block Storage
       (cinder), and the dashboard.<indexterm class="startofrange"
         xml:id="UPubuntu">
@@ -566,7 +566,7 @@ auth_uri = http://controller:5000</programlisting>
         </varlistentry>
 
         <varlistentry>
-          <term>OpenStack Image Service</term>
+          <term>OpenStack Image service</term>
 
           <listitem>
             <screen><prompt>#</prompt> <userinput>service glance-api stop</userinput>
@@ -704,7 +704,7 @@ auth_uri = http://controller:5000</programlisting>
       Enterprise Linux 6.4 or compatible derivatives. Newer minor
       releases should also work. This section primarily addresses
       upgrading core OpenStack services, such as the Identity Service
-      (keystone), Image Service (glance), Compute (nova) including
+      (keystone), Image service (glance), Compute (nova) including
       networking, Block Storage (cinder), and the dashboard.<indexterm
         class="startofrange" xml:id="UPredhat">
         <primary>upgrading</primary>
@@ -974,7 +974,7 @@ flavor = keystone</programlisting>
         </varlistentry>
 
         <varlistentry>
-          <term>OpenStack Image Service</term>
+          <term>OpenStack Image service</term>
 
           <listitem>
             <screen><prompt>#</prompt> <userinput>service openstack-glance-api stop</userinput>
@@ -1085,7 +1085,7 @@ flavor = keystone</programlisting>
       should run Ubuntu 12.04 LTS with Linux kernel 3.11 and the
       latest Havana packages installed and operational. This section
       primarily addresses upgrading core OpenStack services such as
-      Identity (keystone), Image Service (glance), Compute (nova),
+      Identity (keystone), Image service (glance), Compute (nova),
       Networking (neutron), Block Storage (cinder), and the dashboard.
       The Networking upgrade includes conversion from the Open vSwitch
       (OVS) plug-in to the Modular Layer 2 (M2) plug-in. This section
@@ -1254,8 +1254,8 @@ done</userinput></screen>
         </step>
       </procedure>
       <procedure>
-        <title>Upgrade OpenStack Image Service</title>
+        <title>Upgrade OpenStack Image service</title>
-        <para>Before upgrading the Image Service database, you must
+        <para>Before upgrading the Image service database, you must
             convert the character set for each table to UTF-8.</para>
           <step><para>Use the MySQL client to execute the following
             commands:</para>
@@ -1571,7 +1571,7 @@ service_plugins = router</programlisting>
       derivatives such as CentOS and Scientific Linux with the latest
       Havana packages installed and operational. This section
       primarily addresses upgrading core OpenStack services such as
-      Identity (keystone), Image Service (glance), Compute (nova),
+      Identity (keystone), Image service (glance), Compute (nova),
       Networking (neutron), Block Storage (cinder), and the dashboard.
       The Networking upgrade procedure includes conversion from the
       Open vSwitch (OVS) plug-in to the Modular Layer 2 (ML2)
@@ -1733,8 +1733,8 @@ done</userinput>
         </step>
       </procedure>
         <procedure>
-          <title>OpenStack Image Service:</title>
+          <title>OpenStack Image service:</title>
-          <para>Before upgrading the Image Service database, you must convert
+          <para>Before upgrading the Image service database, you must convert
             the character set for each table to UTF-8.</para>
           <step><para>Use the MySQL client to run the following
             commands:</para>
@@ -2073,7 +2073,7 @@ service_plugins = router</programlisting>
     <title>How to Perform an Upgrade from Icehouse to Juno</title>
     <?dbhtml stop-chunking?>
     <para>Use this procedure to upgrade a basic operational deployment of
-      the following services: Identity (keystone), Image Service (glance),
+      the following services: Identity (keystone), Image service (glance),
       Compute (nova), Networking (neutron), dashboard (horizon), Block
       Storage (cinder), Orchestration (heat), and Telemetry (ceilometer).
       This procedure references the basic three-node architecture in the
@@ -2265,7 +2265,7 @@ driver = keystone.token.persistence.backends.sql.Token</programlisting>
           </step>
         </procedure>
         <procedure>
-          <title>Image Service</title>
+          <title>Image service</title>
           <step>
             <para>Edit the <filename>/etc/glance/glance-api.conf</filename>
               file:</para>

doc/openstack-ops/ch_ops_user_facing.xml

@@ -35,7 +35,7 @@
       <title>Adding Images</title>
 
       <para>Several premade images exist and can easily be imported into the
-      Image Service. A common image to add is the CirrOS image, which is very
+      Image service. A common image to add is the CirrOS image, which is very
       small and used for testing purposes.<indexterm class="singular">
           <primary>images</primary>
 
@@ -55,9 +55,9 @@
       <screen><prompt>$</prompt> <userinput>glance help image-create</userinput></screen>
 
       <para>The <code>location</code> option is important to note. It does not
-      copy the entire image into the Image Service, but references an original
+      copy the entire image into the Image service, but references an original
       location where the image can be found. Upon launching an instance of
-      that image, the Image Service accesses the image from the location
+      that image, the Image service accesses the image from the location
       specified.</para>
 
       <para>The <code>copy-from</code> option copies the image from the
@@ -156,16 +156,16 @@
     </section>
 
     <section xml:id="image_service_and_database">
-      <title>The Image Service and the Database</title>
+      <title>The Image service and the Database</title>
 
-      <para>The only thing that the Image Service does not store in a database
+      <para>The only thing that the Image service does not store in a database
-      is the image itself. The Image Service database has two main
+      is the image itself. The Image service database has two main
       tables:<indexterm class="singular">
           <primary>databases</primary>
 
-          <secondary>Image Service</secondary>
+          <secondary>Image service</secondary>
         </indexterm><indexterm class="singular">
-          <primary>Image Service</primary>
+          <primary>Image service</primary>
 
           <secondary>database tables</secondary>
         </indexterm></para>
@@ -187,12 +187,12 @@
     </section>
 
     <section xml:id="sample_image_database">
-      <title>Example Image Service Database Queries</title>
+      <title>Example Image service Database Queries</title>
 
       <para>One interesting example is modifying the table of images and the
       owner of that image. This can be easily done if you simply display the
       unique ID of the owner. <indexterm class="singular">
-          <primary>Image Service</primary>
+          <primary>Image service</primary>
 
           <secondary>database queries</secondary>
         </indexterm>This example goes one step further and displays the
@@ -902,7 +902,7 @@ Optional snapshot description. (Default=None)</programlisting>
         service that holds a file that cloud-aware applications within the
         guest instance can access. For example, <link
         xlink:href="https://help.ubuntu.com/community/CloudInit"
-        xlink:title="OpenStack Image Service">cloudinit</link> is an open
+        xlink:title="OpenStack Image service">cloudinit</link> is an open
         source package from Ubuntu, but available in most distributions, that
         handles early initialization of a cloud instance that makes use of
         this user data.<indexterm class="singular">
@@ -1234,7 +1234,7 @@ Optional snapshot description. (Default=None)</programlisting>
 
         <para>The following section is from Sébastien Han's <link
         xlink:href="http://www.sebastien-han.fr/blog/2012/12/10/openstack-perform-consistent-snapshots/"
-        xlink:title="OpenStack Image Service">“OpenStack: Perform Consistent
+        xlink:title="OpenStack Image service">“OpenStack: Perform Consistent
         Snapshots” blog entry</link>.</para>
 
         <para>A snapshot captures the state of the file system, but not the

doc/openstack-ops/section_arch_example-neutron.xml

@@ -101,7 +101,7 @@
           </tr>
 
           <tr>
-            <td><para>Image Service (glance) backend</para></td>
+            <td><para>Image service (glance) backend</para></td>
 
             <td><para>GlusterFS</para></td>
           </tr>
@@ -332,7 +332,7 @@
           <tr>
             <td>Storage</td>
             <td><para>Storage nodes store all the data required for the
-            environment, including disk images in the Image Service library,
+            environment, including disk images in the Image service library,
             and the persistent storage volumes created by the Block Storage
             service. Storage nodes use GlusterFS technology to keep the data
             highly available and scalable.</para>
@@ -799,21 +799,21 @@
           </tr>
 
           <tr>
-            <td>Image Service (glance)</td>
+            <td>Image service (glance)</td>
 
             <td>Controller</td>
 
             <td><literal>/var/lib/glance/images</literal> is a GlusterFS
             native mount to a Gluster volume off the storage layer.</td>
 
-            <td>The Image Service is run on all controller nodes, ensuring at
+            <td>The Image service is run on all controller nodes, ensuring at
               least one instance will be available in case of node failure. It
               also sits behind HAProxy, which detects when the software fails
               and routes requests around the failing instance.</td>
 
-            <td>The Image Service is run on all controller nodes, so
+            <td>The Image service is run on all controller nodes, so
             scalability can be achieved with additional controller nodes.
-            HAProxy allows scalability for the Image Service as more nodes are
+            HAProxy allows scalability for the Image service as more nodes are
             added.</td>
           </tr>
 

doc/openstack-ops/section_arch_example-nova.xml

@@ -136,7 +136,7 @@
           </tr>
 
           <tr>
-            <td><para>Image Service (glance) back end</para></td>
+            <td><para>Image service (glance) back end</para></td>
 
             <td><para>file</para></td>
           </tr>
@@ -317,7 +317,7 @@
 
       <para>Acknowledging that many small-scale deployments see running Object
       Storage just for the storage of virtual machine images as too costly, we
-      opted for the file back end in the OpenStack Image Service (Glance). If
+      opted for the file back end in the OpenStack Image service (Glance). If
       your cloud will include Object Storage, you can easily add it as a
       back end.</para>