diff --git a/doc/openstack-ops/app_usecases.xml b/doc/openstack-ops/app_usecases.xml
index bc773253..a853fc09 100644
--- a/doc/openstack-ops/app_usecases.xml
+++ b/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>
diff --git a/doc/openstack-ops/ch_arch_cloud_controller.xml b/doc/openstack-ops/ch_arch_cloud_controller.xml
index bc8c8133..bd4483ac 100644
--- a/doc/openstack-ops/ch_arch_cloud_controller.xml
+++ b/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">
@@ -784,4 +784,4 @@
<secondary>design considerations for</secondary>
</indexterm></para>
</section>
-</chapter>
\ No newline at end of file
+</chapter>
diff --git a/doc/openstack-ops/ch_ops_backup_recovery.xml b/doc/openstack-ops/ch_ops_backup_recovery.xml
index 9f6ccbca..2e16c1ac 100644
--- a/doc/openstack-ops/ch_ops_backup_recovery.xml
+++ b/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>
diff --git a/doc/openstack-ops/ch_ops_customize.xml b/doc/openstack-ops/ch_ops_customize.xml
index ca879ca2..96c638f9 100644
--- a/doc/openstack-ops/ch_ops_customize.xml
+++ b/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
diff --git a/doc/openstack-ops/ch_ops_lay_of_land.xml b/doc/openstack-ops/ch_ops_lay_of_land.xml
index 0efb20ab..0ddd59df 100644
--- a/doc/openstack-ops/ch_ops_lay_of_land.xml
+++ b/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
diff --git a/doc/openstack-ops/ch_ops_log_monitor.xml b/doc/openstack-ops/ch_ops_log_monitor.xml
index 2a183588..56c5b160 100644
--- a/doc/openstack-ops/ch_ops_log_monitor.xml
+++ b/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 <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>
diff --git a/doc/openstack-ops/ch_ops_projects_users.xml b/doc/openstack-ops/ch_ops_projects_users.xml
index 7ac0326b..e15f3ea1 100644
--- a/doc/openstack-ops/ch_ops_projects_users.xml
+++ b/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>
diff --git a/doc/openstack-ops/ch_ops_upgrades.xml b/doc/openstack-ops/ch_ops_upgrades.xml
index 21427b9a..83ee0f09 100644
--- a/doc/openstack-ops/ch_ops_upgrades.xml
+++ b/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>
- <para>Before upgrading the Image Service database, you must
+ <title>Upgrade OpenStack Image service</title>
+ <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>
- <para>Before upgrading the Image Service database, you must convert
+ <title>OpenStack Image service:</title>
+ <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>
diff --git a/doc/openstack-ops/ch_ops_user_facing.xml b/doc/openstack-ops/ch_ops_user_facing.xml
index a443dc5e..1391d082 100644
--- a/doc/openstack-ops/ch_ops_user_facing.xml
+++ b/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
- is the image itself. The Image Service database has two main
+ <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
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
diff --git a/doc/openstack-ops/section_arch_example-neutron.xml b/doc/openstack-ops/section_arch_example-neutron.xml
index 483b89e8..9d86a75a 100644
--- a/doc/openstack-ops/section_arch_example-neutron.xml
+++ b/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>
diff --git a/doc/openstack-ops/section_arch_example-nova.xml b/doc/openstack-ops/section_arch_example-nova.xml
index 63396696..2f2f4434 100644
--- a/doc/openstack-ops/section_arch_example-nova.xml
+++ b/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>