openstack/operations-guide
Code Issues Proposed changes

s/Image Service/Image service/g

Browse Source 
Follow conventions for capitalization.

Change-Id: I101efe345710363fa661840227886dc028efb090
This commit is contained in:
Andreas Jaeger 2015-04-15 10:58:01 +02:00
parent eba3c76dc8
commit 9c7f2dbaad
11 changed files with 47 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/openstack-ops/app_usecases.xml
View File

@ -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>

10
doc/openstack-ops/ch_arch_cloud_controller.xml
View File

@ -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>
</chapter>

2
doc/openstack-ops/ch_ops_backup_recovery.xml
View File

@ -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>

4
doc/openstack-ops/ch_ops_customize.xml
View File

@ -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

2
doc/openstack-ops/ch_ops_lay_of_land.xml
View File

@ -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

4
doc/openstack-ops/ch_ops_log_monitor.xml
View File

@ -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>

2
doc/openstack-ops/ch_ops_projects_users.xml
View File

@ -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>

26
doc/openstack-ops/ch_ops_upgrades.xml
View File

@ -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>

24
doc/openstack-ops/ch_ops_user_facing.xml
View File

@ -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

12
doc/openstack-ops/section_arch_example-neutron.xml
View File

@ -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>

4
doc/openstack-ops/section_arch_example-nova.xml
View File

@ -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>