openstack/openstack-manuals
Code Issues Proposed changes

Edited Services sections of Admin Guide

Browse Source 
Edit wording; changed term/description lists to variable lists as per writing
conventions

backport: none
Partial-Bug: #1251195

Change-Id: I3b7f3fedafa79ab64f75260fcd3c5daa7cbb5e34
This commit is contained in:
Darren 2014-05-16 17:27:04 +10:00
parent 9b38a72f75
commit 3981735acd
10 changed files with 430 additions and 447 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

62
doc/common/section_getstart_block-storage.xml
View File

@ -2,39 +2,41 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="block-storage-service">
<title>Block Storage</title>
<para>The Block Storage service enables management of volumes,
volume snapshots, and volume types. It includes the following
<title>OpenStack Block Storage</title>
<para>OpenStack Block Storage enables management of volumes,
volume snapshots, and volume types. It consists of the following
components:</para>
<itemizedlist>
<listitem>
<para><systemitem class="service">cinder-api</systemitem>:
Accepts API requests and routes them to <systemitem
class="service">cinder-volume</systemitem> for
action.</para>
</listitem>
<listitem>
<para><systemitem class="service"
>cinder-volume</systemitem>: Responds to requests to read
from and write to the Block Storage database to maintain
state, interacting with other processes (like <systemitem
class="service">cinder-scheduler</systemitem>) through a
<variablelist>
<varlistentry>
<term><systemitem class="service">cinder-api</systemitem></term>
<listitem><para>Accepts API requests and routes them to <systemitem
class="service">cinder-volume</systemitem> for
action.</para></listitem>
</varlistentry>
<varlistentry>
<term><systemitem class="service">cinder-volume</systemitem></term>
<listitem><para>Responds to requests to read from and write to the
OpenStack Block Storage database to maintain state, interacting with
other processes (like <systemitem
class="service">cinder-scheduler</systemitem>) through a
message queue and directly upon block storage providing
hardware or software. It can interact with a variety of
storage providers through a driver architecture.</para>
</listitem>
<listitem>
<para><systemitem class="service"
>cinder-scheduler</systemitem> daemon: Like the
<systemitem class="service">nova-scheduler</systemitem>,
picks the optimal block storage provider node on which to
create the volume.</para>
</listitem>
<listitem>
<para>Messaging queue: Routes information between the Block
Storage service processes.</para>
</listitem>
</itemizedlist>
<para>The Block Storage service interacts with Compute to
provide volumes for instances.</para>
</varlistentry>
<varlistentry>
<term><systemitem class="service">cinder-scheduler</systemitem>
daemon</term>
<listitem> <para>Like the <systemitem
class="service">nova-scheduler</systemitem>, picks the optimal block
storage provider node on which to create the volume.</para></listitem>
</varlistentry>
<varlistentry>
<term>Messaging queue</term>
<listitem><para>Routes information between the Block Storage
processes.</para></listitem>
</varlistentry>
</variablelist>
<para>OpenStack Block Storage interacts with OpenStack Compute
to provide volumes for instances.</para>
</section>

289
doc/common/section_getstart_compute.xml
View File

@ -2,35 +2,34 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="compute-service">
<title>Compute service</title>
<para>The Compute service is a cloud computing fabric controller,
which is the main part of an IaaS system. Use it to host and
manage cloud computing systems. The main modules are implemented
in Python.</para>
<para>Compute interacts with the Identity Service for
authentication, Image Service for images, and the Dashboard for
the user and administrative interface. Access to images is limited
by project and by user; quotas are limited per project (for
example, the number of instances). The Compute service scales
horizontally on standard hardware, and downloads images to launch
instances as required.</para>
<para>The Compute service is made up of the following functional
areas and their underlying components:</para>
<itemizedlist>
<title>API</title>
<listitem>
<para><systemitem class="service">nova-api</systemitem> service.
Accepts and responds to end user compute API calls. Supports
the OpenStack Compute API, the Amazon EC2 API, and a special
Admin API for privileged users to perform administrative
actions. Also, initiates most orchestration activities, such
as running an instance, and enforces some policies.</para>
<title>OpenStack Compute</title>
<para>OpenStack Compute is used to host and manage cloud computing systems and
is a major part of an infrastructure-as-a-service (IaaS) system. The main
modules are implemented in Python.</para>
<para>OpenStack Compute interacts with OpenStack Identity for
authentication, OpenStack Image Service for images, and OpenStack dashboard
for the user and administrative interface. Access to images is limited
by project and by user; quotas are limited per project (for example, the
number of instances). OpenStack Compute can scale horizontally on standard
hardware, and download images to launch instances.</para>
<para>OpenStack Compute consists of the following areas and their
components:</para>
<variablelist><title>API</title>
<varlistentry>
<term><systemitem class="service">nova-api service</systemitem></term>
<listitem><para>Accepts and responds to end user compute API calls.
Supports the OpenStack Compute API, the Amazon EC2 API, and a special
Admin API for privileged users to perform administrative actions. It
enforces some policies and initiates most orchestration activities,
such as running an instance.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-api-metadata</systemitem>
service. Accepts metadata requests from instances. The
<systemitem class="service">nova-api-metadata</systemitem>
service is generally only used when you run in multi-host mode
</varlistentry>
<varlistentry>
<term><systemitem class="service">nova-api-metadata</systemitem>
service</term>
<listitem><para>Accepts metadata requests from instances. The
<systemitem class="service">nova-api-metadata</systemitem>
service is generally used when you run in multi-host mode
with <systemitem class="service">nova-network</systemitem>
installations. For details, see <link
xlink:href="http://docs.openstack.org/admin-guide-cloud/content/section_metadata-service.html"
@ -38,33 +37,34 @@
Administrator Guide</citetitle>.</para>
<para>On Debian systems, it is included in the <systemitem
class="service">nova-api</systemitem> package, and can be
selected through <package>debconf</package>.</para>
</listitem>
</itemizedlist>
<itemizedlist>
selected through <package>debconf</package>.</para></listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>Compute core</title>
<listitem>
<para><systemitem class="service">nova-compute</systemitem>
process. A worker daemon that creates and terminates virtual
machine instances through hypervisor APIs. For example, XenAPI
for XenServer/XCP, libvirt for KVM or QEMU, VMwareAPI for
VMware, and so on. The process by which it does so is fairly
complex but the basics are simple: Accept actions from the
queue and perform a series of system commands, like launching
a KVM instance, to carry them out while updating state in the
database.</para>
<varlistentry>
<term><systemitem class="service">nova-compute</systemitem>
process</term> <listitem><para>A worker daemon that creates and
terminates virtual machine instances through hypervisor APIs. For
example, XenAPI for XenServer/XCP, libvirt for KVM or QEMU and
VMwareAPI for VMware. Processing is fairly complex but fundamentally it
accepts actions from the queue and performs a series of system
commands, like launching a KVM instance, whilst updating its state in
the database.</para></listitem>
</varlistentry>
<varlistentry>
<term><systemitem class="service">nova-scheduler</systemitem>
process</term>
<listitem><para>Conceptually the simplest piece of code in OpenStack
Compute. It takes a virtual machine instance request from the queue and
determines on which compute server host it will run.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-scheduler</systemitem>
process. Conceptually the simplest piece of code in Compute.
Takes a virtual machine instance request from the queue and
determines on which compute server host it should run.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-conductor</systemitem>
module. Mediates interactions between <systemitem
</varlistentry>
<varlistentry>
<term><systemitem class="service">nova-conductor</systemitem>
module</term><listitem><para>Mediates interactions between <systemitem
class="service">nova-compute</systemitem> and the database.
Aims to eliminate direct accesses to the cloud database made
It eliminates direct accesses to the cloud database made
by <systemitem class="service">nova-compute</systemitem>. The
<systemitem class="service">nova-conductor</systemitem>
module scales horizontally. However, do not deploy it on any
@ -74,34 +74,33 @@
xlink:href="http://russellbryantnet.wordpress.com/2012/11/19/a-new-nova-service-nova-conductor/"
>A new Nova service: nova-conductor</link>.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<title>Networking for VMs</title>
<listitem>
<para><systemitem class="service">nova-network</systemitem>
worker daemon. Similar to <systemitem class="service"
>nova-compute</systemitem>, it accepts networking tasks from
</varlistentry>
</variablelist>
<variablelist><title>Networking for VMs</title>
<varlistentry><term><systemitem class="service">nova-network</systemitem>
worker daemon</term>
<listitem><para>Similar to <systemitem
class="service">nova-compute</systemitem>, it accepts networking tasks from
the queue and performs tasks to manipulate the network, such
as setting up bridging interfaces or changing iptables rules.
This functionality is being migrated to OpenStack Networking,
which is a separate OpenStack service.</para>
This functionality is being migrated to OpenStack Networking.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-dhcpbridge</systemitem>
script. Tracks IP address leases and records them in the
database by using the dnsmasq <literal>dhcp-script</literal>
</varlistentry>
<varlistentry>
<term><systemitem class="service">nova-dhcpbridge</systemitem>
script</term>
<listitem><para>The IP address leases and is recorded in the
database using the dnsmasq <literal>dhcp-script</literal>
facility. This functionality is being migrated to OpenStack
Networking. OpenStack Networking provides a different
script.</para>
</listitem>
</itemizedlist>
Networkin which provides a different script.</para></listitem>
</varlistentry>
</variablelist>
<?hard-pagebreak?>
<itemizedlist>
<title>Console interface</title>
<listitem>
<para><systemitem class="service">nova-consoleauth</systemitem>
daemon. Authorizes tokens for users that console proxies
provide. See <systemitem class="service"
<variablelist><title>Console interface</title>
<varlistentry>
<term><systemitem class="service">nova-consoleauth</systemitem>
daemon</term><listitem><para>Authorizes tokens for users that console
proxies provide. See <systemitem class="service"
>nova-novncproxy</systemitem> and <systemitem
class="service">nova-xvpnvcproxy</systemitem>. This service
must be running for console proxies to work. Many proxies of
@ -109,25 +108,27 @@
class="service">nova-consoleauth</systemitem> service in a
cluster configuration. For information, see <link
xlink:href="http://docs.openstack.org/trunk/config-reference/content/about-nova-consoleauth.html"
>About nova-consoleauth</link>.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-novncproxy</systemitem>
daemon. Provides a proxy for accessing running instances
through a VNC connection. Supports browser-based novnc
clients.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-xvpnvncproxy</systemitem>
daemon. A proxy for accessing running instances through a VNC
connection. Supports a Java client specifically designed for
OpenStack.</para>
</listitem>
<listitem>
<para><systemitem class="service">nova-cert</systemitem> daemon.
Manages x509 certificates.</para>
</listitem>
</itemizedlist>
>About nova-consoleauth</link>.</para></listitem>
</varlistentry>
<varlistentry>
<term><systemitem class="service">nova-novncproxy</systemitem>
daemon</term>
<listitem><para>Provides a proxy for accessing running instances through
a VNC connection. Supports browser-based novnc
clients.</para></listitem>
</varlistentry>
<varlistentry>
<term><systemitem class="service">nova-xvpnvncproxy</systemitem>
daemon</term>
<listitem><para>A proxy for accessing running instances
through a VNC connection. It supports a Java client specifically
designed for OpenStack.</para></listitem>
</varlistentry>
<varlistentry>
<term><systemitem class="service">nova-cert</systemitem> daemon</term>
<listitem><para>x509 certificates.</para></listitem>
</varlistentry>
</variablelist>
<para os="debian">In Debian, a unique
<package>nova-consoleproxy</package> package provides the
<package>nova-novncproxy</package>,
@ -136,63 +137,59 @@
packages, edit the
<filename>/etc/default/nova-consoleproxy</filename> file or use
the <package>debconf</package> interface. You can also manually
edit the <filename>/etc/default/nova-consoleproxy</filename> file
edit the <filename>/etc/default/nova-consoleproxy</filename> file,
and stop and start the console daemons.</para>
<itemizedlist>
<title>Image management (EC2 scenario)</title>
<listitem>
<para><systemitem class="service">nova-objectstore</systemitem>
daemon. Provides an S3 interface for registering images with
the Image Service. Mainly used for installations that must
support euca2ools. The euca2ools tools talk to <systemitem
<variablelist> <title>Image management (EC2 scenario)</title>
<varlistentry>
<term><systemitem class="service">nova-objectstore</systemitem>
daemon</term> <listitem><para>A S3 interface for registering images
with the OpenStack Image Service. It is mainly used for installations
that must support euca2ools. The euca2ools tools talk to <systemitem
class="service">nova-objectstore</systemitem> in <emphasis
role="italic">S3 language</emphasis>, and <systemitem
class="service">nova-objectstore</systemitem> translates S3
requests into Image Service requests.</para>
</listitem>
<listitem>
<para>euca2ools client. A set of command-line interpreter
commands for managing cloud resources. Though not an OpenStack
module, you can configure <systemitem class="service"
>nova-api</systemitem> to support this EC2 interface. For
more information, see the <link
xlink:href="https://www.eucalyptus.com/docs/eucalyptus/3.4/index.html"
>Eucalyptus 3.4 Documentation</link>.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<title>Command-line clients and other interfaces</title>
<listitem>
<para>nova client. Enables users to submit commands as a tenant
administrator or end user.</para>
</listitem>
<listitem>
<para>nova-manage client. Enables cloud administrators to submit
commands.</para>
</listitem>
</itemizedlist>
<itemizedlist>
<title>Other components</title>
<listitem>
<para>The queue. A central hub for passing messages between
daemons. Usually implemented with <link
requests into Image service requests.</para></listitem>
</varlistentry>
<varlistentry>
<term>euca2ools client</term>
<listitem><para>A set of command-line interpreter commands for managing
cloud resources. Although it is not an OpenStack module, you can
configure <systemitem class="service">nova-api</systemitem> to support
this EC2 interface. For more information, see the <link
xlink:href="https://www.eucalyptus.com/docs/eucalyptus/3.4/index.html"
>Eucalyptus 3.4 Documentation</link>.</para></listitem>
</varlistentry>
</variablelist>
<variablelist><title>Command-line clients and other interfaces</title>
<varlistentry><term>nova client</term>
<listitem><para>Allows users to submit commands as a tenant administrator
or end user.</para></listitem>
</varlistentry>
<varlistentry>
<term>nova-manage client</term>
<listitem><para>Enables cloud administrators to submit
commands.</para></listitem>
</varlistentry>
</variablelist>
<variablelist><title>Other components</title>
<varlistentry><term>The queue</term><listitem><para>A central hub for
passing messages between daemons. It is usually implemented with <link
xlink:href="http://www.rabbitmq.com/">RabbitMQ</link>, but
could be any AMQP message queue, such as <link
could be any AMQP message queue, such as <link
xlink:href="http://qpid.apache.org/">Apache Qpid</link> or
<link xlink:href="http://www.zeromq.org/">Zero
MQ</link>.</para>
</listitem>
<listitem>
<para>SQL database. Stores most build-time and runtime states
for a cloud infrastructure. Includes instance types that are
available for use, instances in use, available networks, and
projects. Theoretically, OpenStack Compute can support any
database that SQL-Alchemy supports, but the only databases
widely used are SQLite3 databases (only appropriate for test
and development work), MySQL, and PostgreSQL.</para>
</listitem>
</itemizedlist>
<para>The Compute service interacts with other OpenStack services:
Identity Service for authentication, Image Service for images, and
the OpenStack dashboard for a web interface.</para>
MQ</link>.</para></listitem>
</varlistentry>
<varlistentry><term>SQL database</term>
<listitem><para>Stores most build-time and runtime states for a cloud
infrastructure. It includes instance types that are available for use,
instances in use, available networks, and projects. Theoretically,
OpenStack Compute can support any database that is supported by SQL-Alchemy.
Note the databases which are widely used are SQLite3 databases (for test and
development work), MySQL, and PostgreSQL.</para></listitem>
</varlistentry>
</variablelist>
<para>OpenStack Compute interacts with OpenStack Identity for
authentication; OpenStack Image Service for images; and the OpenStack
dashboard for a web interface.</para>
</section>

4
doc/common/section_getstart_dashboard.xml
View File

@ -2,8 +2,8 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="dashboard-service">
<title>Dashboard</title>
<para>The dashboard is a modular <link
<title>OpenStack dashboard</title>
<para>The OpenStack dashboard is a modular <link
xlink:href="https://www.djangoproject.com/">Django web
application</link> that provides a graphical interface to
OpenStack services.</para>

69
doc/common/section_getstart_image.xml
View File

@ -2,43 +2,46 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="image-service-overview">
<title>Image Service overview</title>
<para>The Image Service includes the following
<title>OpenStack Image Service</title>
<para>The OpenStack Image Service includes the following
components:</para>
<itemizedlist>
<listitem>
<para><systemitem class="service">glance-api</systemitem>.
Accepts Image API calls for image discovery, retrieval,
and storage.</para>
</listitem>
<listitem>
<para><systemitem class="service"
>glance-registry</systemitem>. Stores, processes, and
retrieves metadata about images. Metadata includes items such
as size and type.</para>
<variablelist>
<varlistentry>
<term><systemitem class="service">glance-api</systemitem></term>
<listitem><para>Accepts Image API calls for image discovery,
retrieval, and storage.</para></listitem>
</varlistentry>
<varlistentry>
<term><systemitem class="service">glance-registry</systemitem></term>
<listitem><para>Stores, processes, and retrieves metadata about
images. Metadata includes items such as size and type.</para>
<note><title>Security note</title>
<para>The registry is a private internal service meant only for use
by the Image Service itself. Do not expose it to users.</para></note>
<para>The registry is a private internal service meant for use
by OpenStack Image Service. Do not disclose it to
users.</para></note>
</listitem>
<listitem>
<para>Database. Stores image metadata. You can choose your
database depending on your preference. Most deployments
use MySQL or SQlite.</para>
</listitem>
<listitem>
<para>Storage repository for image files. The Image Service
supports a variety of repositories including normal file systems,
Object Storage, RADOS block devices, HTTP, and Amazon S3. Some
types of repositories support only read-only usage.</para>
</listitem>
</itemizedlist>
<para>A number of periodic processes run on the Image Service to
</varlistentry>
<varlistentry>
<term>Database</term>
<listitem><para>Stores image metadata and you can choose your database
depending on your preference. Most deployments use MySQL or
SQlite.</para></listitem>
</varlistentry>
<varlistentry>
<term>Storage repository for image files</term>
<listitem><para>Various repository types are supported including
normal file systems, Object Storage, RADOS block devices, HTTP, and
Amazon S3. Note that some repositories will only support
read-only usage.</para></listitem>
</varlistentry>
</variablelist>
<para>A number of periodic processes run on the OpenStack Image Service to
support caching. Replication services ensures consistency and
availability through the cluster. Other periodic processes
include auditors, updaters, and reapers.</para>
<para>As shown in <xref linkend="conceptual-architecture"/>, the Image
Service is central to the overall IaaS picture. It accepts API
requests for images or image metadata from end users or
Compute components and can store its disk files in the Object
Storage Service.</para>
<para>The OpenStack Image Service is central to
infrastructure-as-a-service (IaaS) as shown in <xref
linkend="conceptual-architecture"/>. It accepts API requests for images
or image metadata from end users or OpenStack Compute components, and
can store its disk files in OpenStack Object Storage.</para>
</section>

63
doc/common/section_getstart_networking.xml
View File

@ -2,42 +2,39 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="networking-service-overview">
<title>Networking service overview</title>
<para>Provides network-connectivity-as-a-service between interface
devices that are managed by other OpenStack services, usually
Compute. Enables users to create and attach interfaces to
networks. Like many OpenStack services, OpenStack Networking is
highly configurable due to its plug-in architecture. These
plug-ins accommodate different networking equipment and software.
Consequently, the architecture and deployment vary
dramatically.</para>
<para>Includes the following components:</para>
<itemizedlist>
<listitem>
<para><systemitem class="service">neutron-server</systemitem>.
Accepts and routes API requests to the appropriate OpenStack
Networking plug-in for action.</para>
</listitem>
<listitem>
<para>OpenStack Networking plug-ins and agents. Plugs and
unplugs ports, creates networks or subnets, and provides IP
addressing. These plug-ins and agents differ depending on the
vendor and technologies used in the particular cloud.
<title>OpenStack Networking</title>
<para>OpenStack Networking allows you to create and
attach interface devices managed by other OpenStack services to
networks. Plug-ins can be implemented to accomodate different
networking equipment and software, providing flexibility to OpenStack
architecture and deployment.</para>
<para>It includes the following components:</para>
<variablelist>
<varlistentry><term><systemitem
class="service">neutron-server</systemitem></term>
<listitem><para>Accepts and routes API requests to the appropriate
OpenStack Networking plug-in for action.</para></listitem>
</varlistentry>
<varlistentry>
<term>OpenStack Networking plug-ins and agents</term>
<listitem><para>Plugs and unplugs ports, creates networks or subnets,
and provides IP addressing. These plug-ins and agents differ
depending on the vendor and technologies used in the particular cloud.
OpenStack Networking ships with plug-ins and agents for Cisco
virtual and physical switches, NEC OpenFlow products, Open
vSwitch, Linux bridging, Ryu Network Operating System, and
the VMware NSX product.</para>
<para>The common agents are L3 (layer 3), DHCP (dynamic host IP
addressing), and a plug-in agent.</para>
</listitem>
<listitem>
<para>Messaging queue. Most OpenStack Networking installations
make use of a messaging queue to route information between the
neutron-server and various agents as well as a database to
store networking state for particular plug-ins.</para>
</listitem>
</itemizedlist>
<para>OpenStack Networking interacts mainly with OpenStack Compute,
where it provides networks and connectivity for its
instances.</para>
addressing), and a plug-in agent.</para></listitem>
</varlistentry>
<varlistentry>
<term>Messaging queue</term>
<listitem><para>Used by most OpenStack Networking installations to route
information between the neutron-server and various agents, as well as a
database to store networking state for particular
plug-ins.</para></listitem>
</varlistentry>
</variablelist>
<para>OpenStack Networking mainly interacts with OpenStack Compute to
provide networks and connectivity for its instances.</para>
</section>

86
doc/common/section_getstart_object-storage.xml
View File

@ -2,47 +2,49 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="object-storage-service">
<title>Object Storage service</title>
<para>The Object Storage service is a highly scalable and durable
multi-tenant object storage system for large amounts of
unstructured data at low cost through a RESTful HTTP API.</para>
<title>OpenStack Object Storage</title>
<para>The OpenStack Object Storage is a multi-tenant object storage system.
It is highly scalable and can manage large amounts of unstructured data
at low cost through a RESTful HTTP API.</para>
<para>It includes the following components:</para>
<itemizedlist>
<listitem>
<para>Proxy servers (<systemitem class="service"
>swift-proxy-server</systemitem>). Accepts Object Storage
API and raw HTTP requests to upload files, modify metadata,
and create containers. It also serves file or container
listings to web browsers. To improve performance, the proxy
server can use an optional cache usually deployed with
memcache.</para>
</listitem>
<listitem>
<para>Account servers (<systemitem class="service"
>swift-account-server</systemitem>). Manage accounts defined
with the Object Storage service.</para>
</listitem>
<listitem>
<para>Container servers (<systemitem class="service"
>swift-container-server</systemitem>). Manage a mapping of
containers, or folders, within the Object Storage
service.</para>
</listitem>
<listitem>
<para>Object servers (<systemitem class="service"
>swift-object-server</systemitem>). Manage actual objects,
such as files, on the storage nodes.</para>
</listitem>
<listitem>
<para>A number of periodic processes. Performs housekeeping
tasks on the large data store. The replication services ensure
consistency and availability through the cluster. Other
periodic processes include auditors, updaters, and
reapers.</para>
</listitem>
<listitem>
<para>Configurable WSGI middleware that handles authentication.
Usually the Identity Service.</para>
</listitem>
</itemizedlist>
<variablelist>
<varlistentry><term>Proxy servers (<systemitem
class="service">swift-proxy-server</systemitem>)</term>
<listitem><para>Accepts OpenStack Object Storage API and raw HTTP
requests to upload files, modify metadata, and create containers. It
also serves file or container listings to web browsers. To improve
performance, the proxy server can use an optional cache usually
deployed with memcache.</para></listitem>
</varlistentry>
<varlistentry>
<term>Account servers (<systemitem class="service"
>swift-account-server</systemitem>)</term>
<listitem><para>Manages accounts defined with Object
Storage.</para></listitem>
</varlistentry>
<varlistentry>
<term>Container servers (<systemitem class="service"
>swift-container-server</systemitem>)</term>
<listitem><para>Manages the mapping of containers or folders, within
Object Storage.</para></listitem>
</varlistentry>
<varlistentry>
<term>Object servers (<systemitem class="service"
>swift-object-server</systemitem>)</term>
<listitem><para>Manages actual objects,such as files, on the
storage nodes.</para></listitem>
</varlistentry>
<varlistentry>
<term>Various periodic processes</term>
<listitem><para>Performs housekeeping tasks on the large data store.
The replication services ensure consistency and availability through
the cluster. Other periodic processes include auditors, updaters, and
reapers.</para></listitem>
</varlistentry>
<varlistentry>
<term>WSGI middleware</term>
<listitem><para>Handles authentication and is usually OpenStack
Identity.</para></listitem>
</varlistentry>
</variablelist>
</section>

63
doc/common/section_getstart_orchestration.xml
View File

@ -2,42 +2,45 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="orchestration-service">
<title>Orchestration service overview</title>
<para>The Orchestration service provides a template-based
orchestration for describing a cloud application by running
<title>Orchestration module</title>
<para>The Orchestration module provides a template-based
orchestration for describing a cloud application, by running
OpenStack API calls to generate running cloud applications. The
software integrates other core components of OpenStack into a
one-file template system. The templates enable you to create most
one-file template system. The templates allow you to create most
OpenStack resource types, such as instances, floating IPs,
volumes, security groups, users, and so on. Also, provides some
more advanced functionality, such as instance high availability,
instance auto-scaling, and nested stacks. By providing very tight
integration with other OpenStack core projects, all OpenStack core
projects could receive a larger user base.</para>
volumes, security groups and users. It also provides advanced
functionality, such as instance high availability, instance auto-scaling,
and nested stacks. This enables OpenStack core projects to receive a larger
user base.</para>
<para>The service enables deployers to integrate with the
Orchestration service directly or through custom plug-ins.</para>
<para>The Orchestration service consists of the following
Orchestration module directly or through custom plug-ins.</para>
<para>The Orchestration module consists of the following
components:</para>
<itemizedlist>
<listitem>
<para><code>heat</code> command-line client. A CLI that communicates with the
heat-api to run AWS CloudFormation APIs. End developers could
also use the Orchestration REST API directly.</para>
<variablelist>
<varlistentry>
<term><code>heat</code> command-line client</term>
<listitem><para>A CLI that communicates with the heat-api to run AWS
CloudFormation APIs. End developers can directly use the Orchestration
REST API.</para></listitem>
</varlistentry>
<varlistentry>
<term><code>heat-api</code> component</term><listitem><para>An
OpenStack-native REST API that processes API requests by sending them to
the heat-engine over Remote Procedure Call (RPC).</para>
</listitem>
<listitem>
<para><code>heat-api</code> component. Provides an
OpenStack-native REST API that processes API requests by
sending them to the heat-engine over RPC.</para>
</listitem>
<listitem>
<para><code>heat-api-cfn</code> component. Provides an AWS Query
API that is compatible with AWS CloudFormation and processes
</varlistentry>
<varlistentry>
<term><code>heat-api-cfn</code> component</term> <listitem><para>An AWS
Query API that is compatible with AWS CloudFormation. It processes
API requests by sending them to the heat-engine over
RPC.</para>
RPC.</para></listitem>
</varlistentry>
<varlistentry>
<term><code>heat-engine</code></term>
<listitem><para>Orchestrates the launching of templates and provides
events back to the API consumer.</para>
</listitem>
<listitem>
<para><code>heat-engine</code>. Orchestrates the launching of
templates and provides events back to the API consumer.</para>
</listitem>
</itemizedlist>
</varlistentry>
</variablelist>
</section>

95
doc/common/section_getstart_telemetry.xml
View File

@ -2,8 +2,8 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="metering-service">
<title>Telemetry</title>
<para>The Telemetry module:</para>
<title>Telemetry module</title>
<para>The Telemetry module performs the following functions:</para>
<para>
<itemizedlist>
<listitem>
@ -16,7 +16,7 @@
</listitem>
<listitem>
<para>Configures the type of collected data to meet
various operating requirements. Accessing and inserting the
various operating requirements. It accesses and inserts the
metering data through the REST API.</para>
</listitem>
<listitem>
@ -29,55 +29,52 @@
</listitem>
</itemizedlist>
</para>
<para>The system consists of the following basic
<para>The Telemetry module consists of the following
components:</para>
<itemizedlist>
<listitem>
<para>A compute agent (<systemitem class="service"
>ceilometer-agent-compute</systemitem>). Runs on each
compute node and polls
for resource utilization statistics. There may be other
types of agents in the future, but for now we will focus
on creating the compute agent.</para>
<variablelist>
<varlistentry><term>A compute agent (<systemitem class="service"
>ceilometer-agent-compute</systemitem>)</term>
<listitem><para>Runs on each compute node and polls for resource
utilization statistics. There may be other types of agents in the
future, but for now our focus is creating the compute agent.</para>
</listitem>
<listitem>
<para>A central agent (<systemitem class="service"
>ceilometer-agent-central</systemitem>). Runs on a central
management server
to poll for resource utilization statistics for resources
not tied to instances or compute nodes.</para>
</varlistentry>
<varlistentry><term>A central agent (<systemitem class="service"
>ceilometer-agent-central</systemitem>)</term>
<listitem><para>Runs on a central management server to poll for
resource utilization statistics for resources not tied to instances
or compute nodes.</para></listitem>
</varlistentry>
<varlistentry><term>A collector (<systemitem class="service"
>ceilometer-collector</systemitem></term>
<listitem><para>Runs on central management server(s) to monitor the
message queues (for notifications and for metering data coming from
the agent). Notification messages are processed and turned into
metering messages, which are sent to the message bus using the
appropriate topic. Telemetry messages are written to the data store
without modification.</para>
</listitem>
<listitem>
<para>A collector (<systemitem class="service"
>ceilometer-collector</systemitem>). Runs on one or more
central management
servers to monitor the message queues (for notifications
and for metering data coming from the agent). Notification
messages are processed and turned into metering messages
and sent back out onto the message bus using the
appropriate topic. Telemetry messages are written to the
data store without modification.</para>
</listitem>
<listitem>
<para>An alarm notifier (<systemitem class="service"
>ceilometer-alarm-notifier</systemitem>). Runs on one or more
central management servers to allow setting alarms based on
threshold evaluation for a collection of samples.
</para>
</listitem>
<listitem>
<para>A data store. A database capable of handling
</varlistentry>
<varlistentry><term>An alarm notifier (<systemitem class="service"
>ceilometer-alarm-notifier</systemitem>)</term>
<listitem><para>Runs on one or more central management servers to
allow alarms to be set based on the threshold evaluation for a
collection of samples.</para></listitem>
</varlistentry>
<varlistentry>
<term>A data store</term>
<listitem><para>A database capable of handling
concurrent writes (from one or more collector instances)
and reads (from the API server).</para>
</listitem>
<listitem>
<para>An API server (<systemitem class="service"
>ceilometer-api</systemitem>). Runs on one or more central
management
servers to provide access to the data from the data store.</para>
</listitem>
</itemizedlist>
<para>These services communicate by using the standard OpenStack
messaging bus. Only the collector and API server have access
and reads (from the API server).</para></listitem>
</varlistentry>
<varlistentry>
<term>An API server (<systemitem
class="service">ceilometer-api</systemitem>)</term>
<listitem><para>Runs on one or more central management servers to
provide data access from the data store.</para></listitem>
</varlistentry>
</variablelist>
<para>These services communicate by using the OpenStack messaging bus.
Only the collector and API server have access
to the data store.</para>
</section>

117
doc/common/section_keystone-concepts.xml
View File

@ -4,30 +4,27 @@
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="keystone-concepts">
<?dbhtml stop-chunking?>
<title>Identity Service concepts</title>
<para>The <glossterm>Identity Service</glossterm> performs the following
functions:</para>
<title>OpenStack Identity concepts</title>
<para>The OpenStack<glossterm>Identity Service</glossterm> performs the
following functions:</para>
<itemizedlist spacing="compact">
<listitem>
<para>User management. Tracks users and their
permissions.</para>
<para>Tracking users and their permissions.</para>
</listitem>
<listitem>
<para><glossterm baseform="service catalog">Service
catalog</glossterm>. Provides a catalog of available
services with their API endpoints.</para>
<para>Providing a catalog of available services with their API
endpoints.</para>
</listitem>
</itemizedlist>
<para>To understand the Identity Service, you must understand the
<para>To understand OpenStack Identity, you must understand the
following concepts:</para>
<variablelist wordsize="10">
<variablelist>
<varlistentry>
<term><glossterm>User</glossterm>
</term>
<term>User</term>
<listitem>
<para>Digital representation of a person, system, or
service who uses OpenStack cloud services. The
Identity Service validates that incoming requests
Identity service validates that incoming requests
are made by the user who claims to be making the
call. Users have a login and may be assigned
tokens to access resources. Users can be directly
@ -36,50 +33,45 @@
</listitem>
</varlistentry>
<varlistentry>
<term><glossterm>Credentials</glossterm>
</term>
<term>Credentials</term>
<listitem>
<para>Data that is known only by a user that proves
who they are. In the Identity Service, examples
are: User name and password, user name and API
key, or an authentication token provided by the
Identity Service.</para>
<para>Data that confirms the user's identity. For example, user
name and password; user name and API key; or an
authentication token provided by the Identity
Service.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><glossterm>Authentication</glossterm></term>
<term>Authentication</term>
<listitem>
<para>The act of confirming the identity of a user.
The Identity Service confirms an incoming request
<para>The process of confirming the identity of a user.
OpenStack Identity confirms an incoming request
by validating a set of credentials supplied by the
user.</para>
<para>These credentials are initially a user name and
password or a user name and API key. In response
to these credentials, the Identity Service issues
an authentication token to the user, which the
user provides in subsequent requests.</para>
password; or a user name and API key. When user
credentials are validated, OpenStack Identity issues an
authentication token which the user provides in subsequent
requests.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><glossterm>Token</glossterm></term>
<term>Token</term>
<listitem>
<para>An arbitrary bit of text that is used to access
resources. Each token has a scope which describes
which resources are accessible with it. A token
may be revoked at any time and is valid for a
finite duration.</para>
<para>While the Identity Service supports token-based
resources. Each token has information which defines
access to resources. A token may be revoked at any time
and is valid for a finite duration.</para>
<para>While OpenStack Identity supports token-based
authentication in this release, the intention is
for it to support additional protocols in the
future. The intent is for it to be an integration
service foremost, and not aspire to be a
full-fledged identity store and management
to support additional protocols in the future. Its main
purpose is to be an integration service, and not aspire to
be a full-fledged identity store and management
solution.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><glossterm>Tenant</glossterm>
</term>
<term>Tenant</term>
<listitem>
<para>A container used to group or isolate resources
and/or identity objects. Depending on the service
@ -88,47 +80,38 @@
</listitem>
</varlistentry>
<varlistentry>
<term><glossterm>Service</glossterm>
</term>
<term>Service</term>
<listitem>
<para>An OpenStack service, such as Compute (nova),
Object Storage (swift), or Image Service (glance).
Provides one or more endpoints through which users
can access resources and perform
operations.</para>
Object Storage (swift), or Image Service (glance). It
provides one or more endpoints through which users can
access resources and perform operations.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><glossterm>Endpoint</glossterm>
</term>
<term>Endpoint</term>
<listitem>
<para>A network-accessible address, usually described
by a URL, from where you access a service. If using
an extension for templates, you can create an
endpoint template, which represents the templates
of all the consumable services that are available
across the regions.</para>
<para>A network-accessible address where you access a service,
usually a URL address. If you are using an extension for
templates, an endpoint template can be created, which
represents the templates of all the consumable services
that are available across the regions.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><glossterm>Role</glossterm>
</term>
<term>Role</term>
<listitem>
<para>A personality that a user assumes that enables
them to perform a specific set of operations. A
role includes a set of rights and privileges. A
user assuming that role inherits those rights and
privileges.</para>
<para>In the Identity Service, a token that is issued
to a user includes the list of roles that user
has. Services that are being called by that user
determine how they interpret the set of roles a
user has and to which operations or resources each
role grants access.</para>
<para>A personality with a defined set of user rights and
privileges to perform a specific set of operations.</para>
<para>In the Identity service, a token that is issued
to a user includes the list of roles. Services that are
being called by that user determine how they interpret the
set of roles a user has and to which operations or
resources each role grants access.</para>
</listitem>
</varlistentry>
</variablelist>
<para>The following diagram shows the Identity Service process
<para>The following diagram shows the OpenStack Identity process
flow:</para>
<mediaobject>
<imageobject role="fo">

29
doc/common/section_storage-concepts.xml
View File

@ -41,7 +41,7 @@
<tr>
<td>Implemented as a filesystem underlying OpenStack
Compute</td>
<td>Mounted via OpenStack Block-Storage controlled protocol
<td>Mounted via OpenStack Block Storage controlled protocol
(for example, iSCSI)</td>
<td>REST API</td>
</tr>
@ -58,27 +58,26 @@
</tr>
</tbody>
</table>
<?hard-pagebreak?>
<para>Other points of note include: <itemizedlist>
<para>You should note that:<itemizedlist>
<listitem>
<para><emphasis>OpenStack Object Storage is not used like a
traditional hard drive.</emphasis> Object storage is all
about relaxing some of the constraints of a POSIX-style file
system. The access to it is API-based (and the API uses
http). This is a good idea as if you don't have to provide
atomic operations (that is, you can rely on eventual
consistency), you can much more easily scale a storage
system and avoid a central point of failure.</para>
<para><emphasis>You cannot use OpenStack Object Storage like a
traditional hard drive.</emphasis> The Object Storage relaxes some
of the constraints of a POSIX-style file system to get other gains.
You can access the objects through an API which uses HTTP.
Subsequently you don't have to provide atomic operations (that is,
relying on eventual consistency), you can scale a storage system
easily and avoid a central point of failure.</para>
</listitem>
<listitem>
<para><emphasis>The OpenStack Image Service is used to manage
the virtual machine images in an OpenStack cluster, not
store them.</emphasis> Instead, it provides an
abstraction to different methods for storage - a bridge to
the storage, not the storage itself.</para>
store them.</emphasis> It provides an abstraction to different
methods for storage - a bridge to the storage, not the storage
itself.</para>
</listitem>
<listitem>
<para><emphasis>OpenStack Object Storage can function on its
<para><emphasis>The OpenStack Object Storage can function on its
own.</emphasis> The Object Storage (swift) product can be
used independently of the Compute (nova) product.</para>
</listitem>