openstack/operations-guide
Code Issues Proposed changes

Change service names with conventions

Browse Source 
Follow the Documentaion conventions:
https://wiki.openstack.org/wiki/Documentation/Conventions

Change-Id: I16078f5bfc3c47002f43f23be83b03c1f6f938fe
This commit is contained in:
KATO Tomoyuki 2015-06-17 10:52:29 +09:00
parent 341e18b95d
commit 0393934828
15 changed files with 73 additions and 76 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -47,10 +47,10 @@
sites span multiple data centers, some use off compute node storage with 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 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 Object Storage back end. A central Identity, dashboard, and
Compute API service are used. A login to the dashboard triggers a SAML Compute API service are used. A login to the dashboard triggers a SAML
login with Shibboleth, which creates an <glossterm>account</glossterm> login with Shibboleth, which creates an <glossterm>account</glossterm>
in the Identity Service with a SQL back end. An Object Storage Global in the Identity service with a SQL back end. An Object Storage Global
Cluster is used across several sites.</para> Cluster is used across several sites.</para>
<para>Compute nodes have 24 to 48 cores, with at least 4 GB of RAM per <para>Compute nodes have 24 to 48 cores, with at least 4 GB of RAM per
@ -136,7 +136,7 @@
core.</para> core.</para>
<para>With our upgrade to Grizzly in August 2013, we moved to OpenStack <para>With our upgrade to Grizzly in August 2013, we moved to OpenStack
Networking Service, neutron (quantum at the time). Compute nodes have Networking, neutron (quantum at the time). Compute nodes have
two-gigabit network interfaces and a separate management card for IPMI two-gigabit network interfaces and a separate management card for IPMI
management. One network interface is used for node-to-node management. One network interface is used for node-to-node
communications. The other is used as a trunk port for OpenStack managed communications. The other is used as a trunk port for OpenStack managed
@ -267,7 +267,7 @@
instance provisioning.</para> instance provisioning.</para>
<para>Users and groups are managed through Active Directory and imported <para>Users and groups are managed through Active Directory and imported
into the Identity Service using LDAP.&#160;CLIs are available for nova into the Identity service using LDAP.&#160;CLIs are available for nova
and Euca2ools to do this.</para> and Euca2ools to do this.</para>
<para>There are three clouds currently running at CERN, totaling about <para>There are three clouds currently running at CERN, totaling about

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

@ -121,7 +121,7 @@
<listitem> <listitem>
<para>Offers each service's REST API access, where the API endpoint <para>Offers each service's REST API access, where the API endpoint
catalog is managed by the Identity Service</para> catalog is managed by the Identity service</para>
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>
@ -321,7 +321,7 @@
<td><para>This deployment felt that the spare I/O on the Object <td><para>This deployment felt that the spare I/O on the Object
Storage proxy server was sufficient and that the Image Delivery Storage proxy server was sufficient and that the Image Delivery
portion of glance benefited from being on physical hardware and portion of glance benefited from being on physical hardware and
having good connectivity to the Object Storage backend it was having good connectivity to the Object Storage back end it was
using.</para></td> using.</para></td>
</tr> </tr>
@ -587,7 +587,7 @@
<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 <code>glance-api</code> and <code>glance-registry</code>. The former is
responsible for the delivery of images; the compute node uses it to responsible for the delivery of images; the compute node uses it to
download images from the backend. The latter maintains the metadata download images from the back end. The latter maintains the metadata
information associated with virtual machine images and requires a information associated with virtual machine images and requires a
database.<indexterm class="singular"> database.<indexterm class="singular">
<primary>glance</primary> <primary>glance</primary>
@ -612,7 +612,7 @@
</indexterm></para> </indexterm></para>
<para>The <code>glance-api</code> part is an abstraction layer that allows <para>The <code>glance-api</code> part is an abstraction layer that allows
a choice of backend. Currently, it supports:</para> a choice of back end. Currently, it supports:</para>
<variablelist> <variablelist>
<varlistentry> <varlistentry>
@ -705,22 +705,22 @@
group. Resources quotas, such as the number of cores that can be used, group. Resources quotas, such as the number of cores that can be used,
disk space, and so on, are associated with a project.</para> disk space, and so on, are associated with a project.</para>
<para>The OpenStack Identity Service (keystone) is the point that provides <para>OpenStack Identity is the service that provides
the authentication decisions and user attribute information, which is then the authentication decisions and user attribute information, which is then
used by the other OpenStack services to perform authorization. Policy is used by the other OpenStack services to perform authorization. Policy is
set in the <filename>policy.json</filename> file. For <phrase set in the <filename>policy.json</filename> file. For <phrase
role="keep-together">information</phrase> on how to configure these, see role="keep-together">information</phrase> on how to configure these, see
<xref linkend="projects_users" />.<indexterm class="singular"> <xref linkend="projects_users" />.<indexterm class="singular">
<primary>Identity Service</primary> <primary>Identity</primary>
<secondary>authentication decisions</secondary> <secondary>authentication decisions</secondary>
</indexterm><indexterm class="singular"> </indexterm><indexterm class="singular">
<primary>Identity Service</primary> <primary>Identity</primary>
<secondary>plug-in support</secondary> <secondary>plug-in support</secondary>
</indexterm></para> </indexterm></para>
<para>The Identity Service supports different plug-ins for authentication <para>OpenStack Identity supports different plug-ins for authentication
decisions and identity storage. Examples of these plug-ins include:</para> decisions and identity storage. Examples of these plug-ins include:</para>
<itemizedlist role="compact"> <itemizedlist role="compact">
@ -752,7 +752,7 @@
<para>Because the cloud controller handles so many different services, it <para>Because the cloud controller handles so many different services, it
must be able to handle the amount of traffic that hits it. For example, if must be able to handle the amount of traffic that hits it. For example, if
you choose to host the OpenStack Imaging Service on the cloud controller, you choose to host the OpenStack Image service on the cloud controller,
the cloud controller should be able to support the transferring of the the cloud controller should be able to support the transferring of the
images at an acceptable speed.<indexterm class="singular"> images at an acceptable speed.<indexterm class="singular">
<primary>cloud controllers</primary> <primary>cloud controllers</primary>

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

@ -20,7 +20,7 @@
each as well as a rationale for why it worked well in a given each as well as a rationale for why it worked well in a given
environment.</para> environment.</para>
<para>Because OpenStack is highly configurable, with many different backends <para>Because OpenStack is highly configurable, with many different back ends
and network configuration options, it is difficult to write documentation and network configuration options, it is difficult to write documentation
that covers all possible OpenStack deployments. Therefore, this guide that covers all possible OpenStack deployments. Therefore, this guide
defines example architectures to simplify the task of documenting, as well defines example architectures to simplify the task of documenting, as well
@ -48,4 +48,4 @@
or the <link xlink:href="http://www.openstack.org/user-stories/">OpenStack User Stories or the <link xlink:href="http://www.openstack.org/user-stories/">OpenStack User Stories
page</link>.</para> page</link>.</para>
</section> </section>
</chapter> </chapter>

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

@ -193,8 +193,8 @@
<para>These volumes are persistent: they can be detached from one <para>These volumes are persistent: they can be detached from one
instance and re-attached to another, and the data remains intact. Block instance and re-attached to another, and the data remains intact. Block
storage is implemented in OpenStack by the OpenStack Block Storage storage is implemented in OpenStack by the OpenStack Block Storage
(cinder) project, which supports multiple backends in the form of (cinder) project, which supports multiple back ends in the form of
drivers. Your choice of a storage backend must be supported by a Block drivers. Your choice of a storage back end must be supported by a Block
Storage driver.</para> Storage driver.</para>
<para>Most block storage drivers allow the instance to have direct <para>Most block storage drivers allow the instance to have direct
@ -351,14 +351,14 @@
instantly when starting a new instance. For other systems, ephemeral instantly when starting a new instance. For other systems, ephemeral
storage—storage that is released when a VM attached to it is shut down— is storage—storage that is released when a VM attached to it is shut down— is
the preferred way. When you select <glossterm>storage the preferred way. When you select <glossterm>storage
backend</glossterm>s, <indexterm class="singular"> back end</glossterm>s, <indexterm class="singular">
<primary>storage</primary> <primary>storage</primary>
<secondary>choosing backends</secondary> <secondary>choosing back ends</secondary>
</indexterm><indexterm class="singular"> </indexterm><indexterm class="singular">
<primary>storage backend</primary> <primary>storage back end</primary>
</indexterm><indexterm class="singular"> </indexterm><indexterm class="singular">
<primary>backend interactions</primary> <primary>back end interactions</primary>
<secondary>store</secondary> <secondary>store</secondary>
</indexterm>ask the following questions on behalf of your users:</para> </indexterm>ask the following questions on behalf of your users:</para>
@ -609,7 +609,7 @@
<title>Commodity Storage Backend Technologies</title> <title>Commodity Storage Backend Technologies</title>
<para>This section provides a high-level overview of the differences <para>This section provides a high-level overview of the differences
among the different commodity storage backend technologies. Depending on among the different commodity storage back end technologies. Depending on
your cloud user's needs, you can implement one or many of these your cloud user's needs, you can implement one or many of these
technologies in different combinations:<indexterm class="singular"> technologies in different combinations:<indexterm class="singular">
<primary>storage</primary> <primary>storage</primary>
@ -661,7 +661,7 @@
storage, and file-system interfaces, although the file-system storage, and file-system interfaces, although the file-system
interface is not yet considered production-ready. Ceph supports interface is not yet considered production-ready. Ceph supports
the same API as swift for object storage and can be used as a the same API as swift for object storage and can be used as a
backend for cinder block storage as well as backend storage for back end for cinder block storage as well as back-end storage for
glance images. Ceph supports "thin provisioning," implemented glance images. Ceph supports "thin provisioning," implemented
using copy-on-write.</para> using copy-on-write.</para>
@ -697,7 +697,7 @@
3.3, you can use Gluster to consolidate your object storage and 3.3, you can use Gluster to consolidate your object storage and
file storage into one unified file and object storage solution, file storage into one unified file and object storage solution,
which is called Gluster For OpenStack (GFO). GFO uses a customized which is called Gluster For OpenStack (GFO). GFO uses a customized
version of swift that enables Gluster to be used as the backend version of swift that enables Gluster to be used as the back-end
storage.</para> storage.</para>
<para>The main reason to use GFO rather than regular swift is if <para>The main reason to use GFO rather than regular swift is if
@ -717,7 +717,7 @@
<listitem> <listitem>
<para>The Logical Volume Manager is a Linux-based system that <para>The Logical Volume Manager is a Linux-based system that
provides an abstraction layer on top of physical disks to expose provides an abstraction layer on top of physical disks to expose
logical volumes to the operating system. The LVM backend logical volumes to the operating system. The LVM back-end
implements block storage as LVM logical partitions.</para> implements block storage as LVM logical partitions.</para>
<para>On each host that will house block storage, an administrator <para>On each host that will house block storage, an administrator
@ -748,7 +748,7 @@
number of advantages over ext4, including improved data-integrity number of advantages over ext4, including improved data-integrity
checking.</para> checking.</para>
<para>The ZFS backend for OpenStack Block Storage supports only <para>The ZFS back end for OpenStack Block Storage supports only
Solaris-based systems, such as Illumos. While there is a Linux Solaris-based systems, such as Illumos. While there is a Linux
port of ZFS, it is not included in any of the standard Linux port of ZFS, it is not included in any of the standard Linux
distributions, and it has not been tested with OpenStack Block distributions, and it has not been tested with OpenStack Block
@ -758,7 +758,7 @@
failures.</para> failures.</para>
<para>We don't recommend ZFS unless you have previous experience <para>We don't recommend ZFS unless you have previous experience
with deploying it, since the ZFS backend for Block Storage with deploying it, since the ZFS back end for Block Storage
requires a Solaris-based operating system, and we assume that your requires a Solaris-based operating system, and we assume that your
experience is primarily with Linux-based systems.</para> experience is primarily with Linux-based systems.</para>
</listitem> </listitem>

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

@ -166,7 +166,7 @@ find $backup_dir -ctime +7 -type f -delete</programlisting>
<para><code>/var/lib/glance</code> should also be backed up. Take <para><code>/var/lib/glance</code> should also be backed up. Take
special notice of <code>/var/lib/glance/images</code>. If you are using special notice of <code>/var/lib/glance/images</code>. If you are using
a file-based backend of glance, <code>/var/lib/glance/images</code> is a file-based back end of glance, <code>/var/lib/glance/images</code> is
where the images are stored and care should be taken.</para> where the images are stored and care should be taken.</para>
<para>There are two ways to ensure stability with this directory. The <para>There are two ways to ensure stability with this directory. The
@ -183,7 +183,7 @@ backup-server:/var/lib/glance/images/</programlisting>
<para><code>/etc/keystone</code> and <code>/var/log/keystone</code> <para><code>/etc/keystone</code> and <code>/var/log/keystone</code>
follow the same rules as other components.<indexterm class="singular"> follow the same rules as other components.<indexterm class="singular">
<primary>Identity Service</primary> <primary>Identity</primary>
<secondary>backup/recovery</secondary> <secondary>backup/recovery</secondary>
</indexterm></para> </indexterm></para>

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

@ -243,7 +243,7 @@ RABBIT_PASSWORD=devstack
SERVICE_PASSWORD=devstack SERVICE_PASSWORD=devstack
SERVICE_TOKEN=devstack SERVICE_TOKEN=devstack
# OpenStack Identity Service branch # OpenStack Identity branch
KEYSTONE_BRANCH=stable/havana KEYSTONE_BRANCH=stable/havana
# OpenStack Compute branch # OpenStack Compute branch
@ -255,7 +255,7 @@ CINDER_BRANCH=stable/havana
# OpenStack Image service branch # OpenStack Image service branch
GLANCE_BRANCH=stable/havana GLANCE_BRANCH=stable/havana
# OpenStack Dashboard branch # OpenStack dashboard branch
HORIZON_BRANCH=stable/havana HORIZON_BRANCH=stable/havana
# OpenStack Object Storage branch # OpenStack Object Storage branch

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

@ -502,10 +502,10 @@ cloud.example.com nova</programlisting>
<para>With these two tables, you now have a good overview of what <para>With these two tables, you now have a good overview of what
servers and services make up your cloud.</para> servers and services make up your cloud.</para>
<para>You can also use the Identity Service (keystone) to see what <para>You can also use the Identity service (keystone) to see what
services are available in your cloud as well as what endpoints have been services are available in your cloud as well as what endpoints have been
configured for the services.<indexterm class="singular"> configured for the services.<indexterm class="singular">
<primary>Identity Service</primary> <primary>Identity</primary>
<secondary>displaying services and endpoints with</secondary> <secondary>displaying services and endpoints with</secondary>
</indexterm></para> </indexterm></para>

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

@ -209,7 +209,7 @@
2013-02-25 21:05:51 17409 TRACE cinder</computeroutput></screen> 2013-02-25 21:05:51 17409 TRACE cinder</computeroutput></screen>
<para>In this example, <literal>cinder-volumes</literal> failed to start <para>In this example, <literal>cinder-volumes</literal> failed to start
and has provided a stack trace, since its volume backend has been unable and has provided a stack trace, since its volume back end has been unable
to set up the storage volume—probably because the LVM volume that is to set up the storage volume—probably because the LVM volume that is
expected from the configuration does not exist.</para> expected from the configuration does not exist.</para>
@ -825,7 +825,7 @@ notification_driver=messagingv2</programlisting>
<para>But how can you tell whether images are being successfully <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 storing the images on is full or the S3 back end is down. You could
naturally check this by doing a quick image upload:</para> naturally check this by doing a quick image upload:</para>
<?hard-pagebreak ?> <?hard-pagebreak ?>

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

@ -928,7 +928,7 @@ inner join nova.instances on cinder.volumes.instance_uuid=nova.instances.uuid
deployed to your cloud: use an automated deployment system to bootstrap deployed to your cloud: use an automated deployment system to bootstrap
the bare-metal server with the operating system and then have a the bare-metal server with the operating system and then have a
configuration-management system install and configure OpenStack Compute. configuration-management system install and configure OpenStack Compute.
Once the Compute Service has been installed and configured in the same Once the Compute service has been installed and configured in the same
way as the other compute nodes, it automatically attaches itself to the way as the other compute nodes, it automatically attaches itself to the
cloud. The cloud controller notices the new node(s) and begins cloud. The cloud controller notices the new node(s) and begins
scheduling instances to launch there.<indexterm class="singular"> scheduling instances to launch there.<indexterm class="singular">

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

@ -145,9 +145,9 @@
<title>Visualizing OpenStack Networking Service Traffic in the <title>Visualizing OpenStack Networking Service Traffic in the
Cloud</title> Cloud</title>
<para>The OpenStack Networking Service, neutron, has many more degrees of <para>OpenStack Networking has many more degrees of
freedom than <literal>nova-network</literal> does because of its pluggable freedom than <literal>nova-network</literal> does because of its pluggable
backend. It can be configured with open source or vendor proprietary back end. It can be configured with open source or vendor proprietary
plug-ins that control software defined networking (SDN) hardware or plug-ins that control software defined networking (SDN) hardware or
plug-ins that use Linux native facilities on your hosts, such as Open plug-ins that use Linux native facilities on your hosts, such as Open
vSwitch or Linux Bridge.<indexterm class="startofrange" xml:id="Topen"> vSwitch or Linux Bridge.<indexterm class="startofrange" xml:id="Topen">
@ -164,8 +164,8 @@
various components involved however they are plumbed together in your various components involved however they are plumbed together in your
environment.</para> environment.</para>
<para>For this example, we will use the Open vSwitch (OVS) backend. Other <para>For this example, we will use the Open vSwitch (OVS) back end. Other
backend plug-ins will have very different flow paths. OVS is the most back-end plug-ins will have very different flow paths. OVS is the most
popularly deployed network driver, according to the October 2013 OpenStack popularly deployed network driver, according to the October 2013 OpenStack
User Survey, with 50 percent more sites using it than the second place User Survey, with 50 percent more sites using it than the second place
Linux Bridge driver. We'll describe each step in turn, with <xref Linux Bridge driver. We'll describe each step in turn, with <xref
@ -1134,7 +1134,7 @@ proto UDP (17), length 75)
<section xml:id="trouble_shooting_ovs"> <section xml:id="trouble_shooting_ovs">
<title>Troubleshooting Open vSwitch</title> <title>Troubleshooting Open vSwitch</title>
<para>Open vSwitch, as used in the previous OpenStack Networking Service <para>Open vSwitch, as used in the previous OpenStack Networking
examples is a full-featured multilayer virtual switch licensed under the examples is a full-featured multilayer virtual switch licensed under the
open source Apache 2.0 license. Full documentation can be found at <link open source Apache 2.0 license. Full documentation can be found at <link
xlink:href="http://openvswitch.org/">the project's website</link>. In xlink:href="http://openvswitch.org/">the project's website</link>. In

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

@ -20,9 +20,9 @@
<para>While version 3 of the Identity API is available, the client tools <para>While version 3 of the Identity API is available, the client tools
do not yet implement those calls, and most OpenStack clouds are still do not yet implement those calls, and most OpenStack clouds are still
implementing Identity API v2.0.<indexterm class="singular"> implementing Identity API v2.0.<indexterm class="singular">
<primary>Identity Service</primary> <primary>Identity</primary>
<secondary>Identity Service API</secondary> <secondary>Identity service API</secondary>
</indexterm></para> </indexterm></para>
</warning> </warning>
@ -46,10 +46,10 @@
<secondary>definition of</secondary> <secondary>definition of</secondary>
</indexterm></para> </indexterm></para>
<para>The initial implementation of the OpenStack Compute Service (nova) <para>The initial implementation of OpenStack Compute
had its own authentication system and used the term had its own authentication system and used the term
<literal>project</literal>. When authentication moved into the OpenStack <literal>project</literal>. When authentication moved into the OpenStack
Identity Service (keystone) project, it used the term Identity (keystone) project, it used the term
<literal>tenant</literal> to refer to a group of users. Because of this <literal>tenant</literal> to refer to a group of users. Because of this
legacy, some of the OpenStack tools refer to projects and some refer to legacy, some of the OpenStack tools refer to projects and some refer to
tenants.</para> tenants.</para>
@ -156,7 +156,7 @@
</warning> </warning>
<para>Using the command-line interface, you can manage quotas for the <para>Using the command-line interface, you can manage quotas for the
OpenStack Compute Service and the Block Storage Service.</para> OpenStack Compute service and the Block Storage service.</para>
<para>Typically, default values are changed because a tenant requires more <para>Typically, default values are changed because a tenant requires more
than the OpenStack default of 10 volumes per tenant, or more than the than the OpenStack default of 10 volumes per tenant, or more than the
@ -217,12 +217,12 @@
<section xml:id="cli_set_compute_quotas"> <section xml:id="cli_set_compute_quotas">
<title>Set Compute Service Quotas</title> <title>Set Compute Service Quotas</title>
<para>As an administrative user, you can update the Compute Service <para>As an administrative user, you can update the Compute service
quotas for an existing tenant, as well as update the quota defaults for quotas for an existing tenant, as well as update the quota defaults for
a new tenant.<indexterm class="singular"> a new tenant.<indexterm class="singular">
<primary>Compute</primary> <primary>Compute</primary>
<secondary>Compute Service</secondary> <secondary>Compute service</secondary>
</indexterm> See <xref linkend="compute-quota-table" />.</para> </indexterm> See <xref linkend="compute-quota-table" />.</para>
<table rules="all" xml:id="compute-quota-table"> <table rules="all" xml:id="compute-quota-table">
@ -593,7 +593,7 @@ Accept-Ranges: bytes</computeroutput></screen>
<title>Set Block Storage Quotas</title> <title>Set Block Storage Quotas</title>
<para>As an administrative user, you can update the Block Storage <para>As an administrative user, you can update the Block Storage
Service quotas for a tenant, as well as update the quota defaults for a service quotas for a tenant, as well as update the quota defaults for a
new tenant. See <xref linkend="block-storage-quota-table" />.<indexterm new tenant. See <xref linkend="block-storage-quota-table" />.<indexterm
class="singular"> class="singular">
<primary>Block Storage</primary> <primary>Block Storage</primary>

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

@ -216,21 +216,20 @@
<orderedlist> <orderedlist>
<listitem> <listitem>
<para>Upgrade the OpenStack Identity Service <para>Upgrade OpenStack Identity.</para>
(keystone).</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Upgrade the OpenStack Image service (glance).</para> <para>Upgrade the OpenStack Image service.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Upgrade OpenStack Compute (nova), including networking <para>Upgrade OpenStack Compute, including networking
components.</para> components.</para>
</listitem> </listitem>
<listitem> <listitem>
<para>Upgrade OpenStack Block Storage (cinder).</para> <para>Upgrade OpenStack Block Storage.</para>
</listitem> </listitem>
<listitem> <listitem>
@ -332,9 +331,8 @@ scheduler=havana</programlisting>
Installation Guide</citetitle></link> and upgrading to the Installation Guide</citetitle></link> and upgrading to the
same architecture for Havana. All nodes should run Ubuntu 12.04 same architecture for Havana. All nodes should run Ubuntu 12.04
LTS. This section primarily addresses upgrading core OpenStack LTS. This section primarily addresses upgrading core OpenStack
services, such as the Identity Service (keystone), Image service services, such as Identity, Image service, Compute including networking,
(glance), Compute (nova) including networking, Block Storage Block Storage, and the dashboard.<indexterm class="startofrange"
(cinder), and the dashboard.<indexterm class="startofrange"
xml:id="UPubuntu"> xml:id="UPubuntu">
<primary>upgrading</primary> <primary>upgrading</primary>
<secondary>Grizzly to Havana (Ubuntu)</secondary> <secondary>Grizzly to Havana (Ubuntu)</secondary>
@ -703,10 +701,9 @@ auth_uri = http://controller:5000</programlisting>
same architecture for Havana. All nodes should run Red Hat same architecture for Havana. All nodes should run Red Hat
Enterprise Linux 6.4 or compatible derivatives. Newer minor Enterprise Linux 6.4 or compatible derivatives. Newer minor
releases should also work. This section primarily addresses releases should also work. This section primarily addresses
upgrading core OpenStack services, such as the Identity Service upgrading core OpenStack services, such as the Identity,
(keystone), Image service (glance), Compute (nova) including Image service, Compute including networking, Block Storage,
networking, Block Storage (cinder), and the dashboard.<indexterm and the dashboard.<indexterm class="startofrange" xml:id="UPredhat">
class="startofrange" xml:id="UPredhat">
<primary>upgrading</primary> <primary>upgrading</primary>
<secondary>Grizzly to Havana (Red Hat)</secondary> <secondary>Grizzly to Havana (Red Hat)</secondary>
</indexterm></para> </indexterm></para>

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

@ -68,7 +68,7 @@
</variablelist> </variablelist>
<para>As shown, end users can interact through the dashboard, CLIs, and <para>As shown, end users can interact through the dashboard, CLIs, and
APIs. All services authenticate through a common Identity Service, and APIs. All services authenticate through a common Identity service, and
individual services interact with each other through public APIs, except individual services interact with each other through public APIs, except
where privileged administrator commands are necessary. <xref where privileged administrator commands are necessary. <xref
linkend="openstack-diagram" /> shows the most common, but not the linkend="openstack-diagram" /> shows the most common, but not the

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

@ -101,19 +101,19 @@
</tr> </tr>
<tr> <tr>
<td><para>Image service (glance) backend</para></td> <td><para>Image service back end</para></td>
<td><para>GlusterFS</para></td> <td><para>GlusterFS</para></td>
</tr> </tr>
<tr> <tr>
<td><para>Identity Service (keystone) driver</para></td> <td><para>Identity driver</para></td>
<td><para>SQL</para></td> <td><para>SQL</para></td>
</tr> </tr>
<tr> <tr>
<td><para>Block Storage Service (cinder) backend</para></td> <td><para>Block Storage back end</para></td>
<td><para>GlusterFS</para></td> <td><para>GlusterFS</para></td>
</tr> </tr>
@ -176,7 +176,7 @@
<term>MySQL</term> <term>MySQL</term>
<listitem> <listitem>
<para>MySQL is used as the database backend for all databases in <para>MySQL is used as the database back end for all databases in
the OpenStack environment. MySQL is the supported database of the OpenStack environment. MySQL is the supported database of
choice for Red Hat Enterprise Linux (and included in choice for Red Hat Enterprise Linux (and included in
distribution); the database is open source, scalable, and handles distribution); the database is open source, scalable, and handles
@ -863,7 +863,7 @@
role="keep-together"><literal>qpid_heartbeat = </literal><phrase role="keep-together"><literal>qpid_heartbeat = </literal><phrase
role="keep-together"><literal>10</literal>,</phrase></phrase><phrase role="keep-together"><literal>10</literal>,</phrase></phrase><phrase
role="keep-together"> configured to use a Gluster</phrase> volume role="keep-together"> configured to use a Gluster</phrase> volume
from the storage layer as the backend for Block Storage, using the from the storage layer as the back end for Block Storage, using the
Gluster native client.</td> Gluster native client.</td>
<td>Block Storage API, scheduler, and volume services are run on all <td>Block Storage API, scheduler, and volume services are run on all

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

@ -142,13 +142,13 @@
</tr> </tr>
<tr> <tr>
<td><para>Identity Service (keystone) driver</para></td> <td><para>Identity (keystone) driver</para></td>
<td><para>SQL</para></td> <td><para>SQL</para></td>
</tr> </tr>
<tr> <tr>
<td><para>Block Storage Service (cinder) back end</para></td> <td><para>Block Storage (cinder) back end</para></td>
<td><para>LVM/iSCSI</para></td> <td><para>LVM/iSCSI</para></td>
</tr> </tr>
@ -321,8 +321,8 @@
your cloud will include Object Storage, you can easily add it as a your cloud will include Object Storage, you can easily add it as a
back end.</para> back end.</para>
<para>We chose the <emphasis>SQL back end for the Identity Service <para>We chose the <emphasis>SQL back end for Identity</emphasis>
(keystone)</emphasis> over others, such as LDAP. This back end is simple over others, such as LDAP. This back end is simple
to install and is robust. The authors acknowledge that many to install and is robust. The authors acknowledge that many
installations want to bind with existing directory services and caution installations want to bind with existing directory services and caution
careful understanding of the <link xlink:href="http://docs.openstack.org/havana/config-reference/content/ch_configuring-openstack-identity.html#configuring-keystone-for-ldap-backend" careful understanding of the <link xlink:href="http://docs.openstack.org/havana/config-reference/content/ch_configuring-openstack-identity.html#configuring-keystone-for-ldap-backend"
@ -331,7 +331,7 @@
<para>Block Storage (cinder) is installed natively on external storage <para>Block Storage (cinder) is installed natively on external storage
nodes and uses the <emphasis>LVM/iSCSI plug-in</emphasis>. Most Block nodes and uses the <emphasis>LVM/iSCSI plug-in</emphasis>. Most Block
Storage Service plug-ins are tied to particular vendor products and Storage plug-ins are tied to particular vendor products and
implementations limiting their use to consumers of those hardware implementations limiting their use to consumers of those hardware
platforms, but LVM/iSCSI is robust and stable on commodity platforms, but LVM/iSCSI is robust and stable on commodity
hardware.</para> hardware.</para>
@ -346,15 +346,15 @@
</section> </section>
<section xml:id="neutron"> <section xml:id="neutron">
<title>Why not use the OpenStack Network Service (neutron)?</title> <title>Why not use OpenStack Networking?</title>
<para>This example architecture does not use the OpenStack Network <para>This example architecture does not use OpenStack Networking,
Service (neutron), because it does not yet support multi-host networking because it does not yet support multi-host networking
and our organizations (university, government) have access to a large and our organizations (university, government) have access to a large
range of publicly-accessible IPv4 addresses.<indexterm class="singular"> range of publicly-accessible IPv4 addresses.<indexterm class="singular">
<primary>legacy networking (nova)</primary> <primary>legacy networking (nova)</primary>
<secondary>vs. OpenStack Network Service (neutron)</secondary> <secondary>vs. OpenStack Networking (neutron)</secondary>
</indexterm></para> </indexterm></para>
</section> </section>