64b6c9261e
Current folder name New folder name Book title ---------------------------------------------------------- basic-install DELETE cli-guide DELETE common common NEW admin-guide-cloud Cloud Administrators Guide docbkx-example DELETE openstack-block-storage-admin DELETE openstack-compute-admin DELETE openstack-config config-reference OpenStack Configuration Reference openstack-ha high-availability-guide OpenStack High Availabilty Guide openstack-image image-guide OpenStack Virtual Machine Image Guide openstack-install install-guide OpenStack Installation Guide openstack-network-connectivity-admin admin-guide-network OpenStack Networking Administration Guide openstack-object-storage-admin DELETE openstack-security security-guide OpenStack Security Guide openstack-training training-guide OpenStack Training Guide openstack-user user-guide OpenStack End User Guide openstack-user-admin user-guide-admin OpenStack Admin User Guide glossary NEW OpenStack Glossary bug: #1220407 Change-Id: Id5ffc774b966ba7b9a591743a877aa10ab3094c7 author: diane fleming
293 lines
14 KiB
XML
293 lines
14 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<chapter xml:id="terminology"
|
|
xmlns="http://docbook.org/ns/docbook"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
|
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0">
|
|
<title>OpenStack Terminology</title>
|
|
|
|
<section xml:id="version">
|
|
<title>Version Names and Release Notes</title>
|
|
<para>Each OpenStack release has a name, in increasing alphabetical order (e.g., Havana
|
|
follows Grizzly). There are also version numbers corresponding to these releases,
|
|
as shown in the table below. Click on a release name in the table (e.g., Grizzly) for
|
|
the release notes, which are hosted on the OpenStack wiki.<table rules="all">
|
|
<caption>OpenStack version names</caption>
|
|
<thead>
|
|
<tr>
|
|
<td>Release name</td>
|
|
<td>Release date</td>
|
|
<td>OpenStack version number for Block Storage, Compute, Identity, Image, and Networking</td>
|
|
<td>OpenStack Object Storage version number</td>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td>Havana</td>
|
|
<td>October 2013</td>
|
|
<td>2013.3</td>
|
|
<td>unknown</td>
|
|
</tr>
|
|
<tr>
|
|
<td><link xlink:href="http://wiki.openstack.org/ReleaseNotes/Grizzly"
|
|
>Grizzly</link></td>
|
|
<td>April 2013</td>
|
|
<td>2013.1</td>
|
|
<td>1.7.6</td>
|
|
</tr>
|
|
<tr>
|
|
<td><link xlink:href="http://wiki.openstack.org/ReleaseNotes/Folsom"
|
|
>Folsom</link></td>
|
|
<td>October 2012</td>
|
|
<td>2012.2</td>
|
|
<td>1.7.2</td>
|
|
</tr>
|
|
<tr>
|
|
<td><link xlink:href="http://wiki.openstack.org/ReleaseNotes/Essex"
|
|
>Essex</link></td>
|
|
<td>April 2012</td>
|
|
<td>2012.1</td>
|
|
<td>1.4.8</td>
|
|
</tr>
|
|
<tr>
|
|
<td><link xlink:href="http://wiki.openstack.org/ReleaseNotes/Diablo"
|
|
>Diablo</link></td>
|
|
<td>October 2011</td>
|
|
<td>2011.3</td>
|
|
<td>1.4.3</td>
|
|
</tr>
|
|
<tr>
|
|
<td><link xlink:href="http://wiki.openstack.org/ReleaseNotes/Cactus"
|
|
>Cactus</link></td>
|
|
<td>April 2011</td>
|
|
<td>2011.2</td>
|
|
<td>1.3.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td><link xlink:href="http://wiki.openstack.org/ReleaseNotes/Bexar"
|
|
>Bexar</link></td>
|
|
<td>March 2011</td>
|
|
<td>2011.1</td>
|
|
<td>1.2.0</td>
|
|
</tr>
|
|
<tr>
|
|
<td><link xlink:href="http://wiki.openstack.org/ReleaseNotes/Austin"
|
|
>Austin</link></td>
|
|
<td>October 2010</td>
|
|
<td>0.9.0</td>
|
|
<td>1.0.0</td>
|
|
</tr>
|
|
</tbody>
|
|
</table> Beginning with the Cactus release, OpenStack adopted a six month release
|
|
schedule. The Havana release is scheduled for October 2013.</para>
|
|
</section>
|
|
|
|
|
|
<section xml:id="terminology-codenames">
|
|
<title>Code Names</title>
|
|
<para>Each OpenStack service has a code name. For example, the
|
|
Image Service is code-named Glance. The full list is shown
|
|
in the table below: <table rules="all" width="100%">
|
|
<caption>Code names</caption>
|
|
<col width="50%"/>
|
|
<col width="50%"/>
|
|
<thead>
|
|
<tr>
|
|
<td>Service name</td>
|
|
<td>Code name</td>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td>
|
|
<para>Identity</para>
|
|
</td>
|
|
<td>
|
|
<para>Keystone</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>Compute</para>
|
|
</td>
|
|
<td>
|
|
<para>Nova</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>Image</para>
|
|
</td>
|
|
<td>
|
|
<para>Glance</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>Dashboard</para>
|
|
</td>
|
|
<td>
|
|
<para>Horizon</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>Object Storage</para>
|
|
</td>
|
|
<td>
|
|
<para>Swift</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>Volumes</para>
|
|
</td>
|
|
<td>
|
|
<para>Cinder</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>Networking</para>
|
|
</td>
|
|
<td>
|
|
<para>Neutron</para>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</para>
|
|
<para>These code names are reflected in the names of configuration
|
|
files and command-line utility programs. For example, the Identity
|
|
service has a configuration file called
|
|
<filename>keystone.conf</filename>.
|
|
</para>
|
|
<para>In addition, projects can go through an incubation phase
|
|
and become integrated with other OpenStack services that
|
|
release as a group with integrated testing. Two projects
|
|
went through that process and will be integrated with the
|
|
Havana release:</para>
|
|
<table rules="all" width="100%">
|
|
<caption>Code names</caption>
|
|
<col width="50%"/>
|
|
<col width="50%"/>
|
|
<thead>
|
|
<tr>
|
|
<td>Service name</td>
|
|
<td>Code name</td>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr>
|
|
<td>
|
|
<para>Metering</para>
|
|
</td>
|
|
<td>
|
|
<para>Ceilometer</para>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<para>Orchestration</para>
|
|
</td>
|
|
<td>
|
|
<para>Heat</para>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</section>
|
|
<section xml:id="terminology-services">
|
|
<title>OpenStack Services and Linux Services</title>
|
|
<para>In the Linux world, a service (also known as a daemon) refers to
|
|
a single program that runs in the background and typically listens
|
|
on a port to respond to service requests. An OpenStack service, on
|
|
the other hand, refers to a collection of Linux services working
|
|
in concert.</para>
|
|
<para>OpenStack services are implemented by multiple Linux services.
|
|
For example, <systemitem class="service">nova-compute</systemitem> and <systemitem class="service">nova-scheduler</systemitem>
|
|
are two of the Linux services that implement the Compute service.
|
|
OpenStack also depends on several third-party services, such as a
|
|
database (typically MySQL) and a message broker (typically RabbitMQ
|
|
or Qpid).
|
|
</para>
|
|
<para>In this document, we generally use the term "service" to refer
|
|
both to lower-level Linux services and higher-level OpenStack
|
|
services. It should be clear from the context whether we are
|
|
referring to a high-level OpenStack service (e.g., Image), or a
|
|
low-level Linux service (e.g., <systemitem class="service">glance-api</systemitem>).</para>
|
|
</section>
|
|
<section xml:id="terminology-storage">
|
|
<?dbhtml stop-chunking?>
|
|
<title>Storage: objects, blocks, and files</title>
|
|
<para>Many cloud computing use cases require persistent remote storage. Storage solutions
|
|
are often divided into three categories: object storage, block storage, and file
|
|
storage.</para>
|
|
<para>Note that some storage solutions support multiple categories. For example, <link
|
|
xlink:href="http://nexenta.com">NexentaStor</link> supports both block storage and
|
|
file storage (with announcements for future support for object storage), <link
|
|
xlink:href="http://www.gluster.org">GlusterFS</link> supports file storage and
|
|
object storage, and <link xlink:href="http://ceph.com">Ceph Storage</link> supports
|
|
object storage, block storage, and file storage.</para>
|
|
<section xml:id="terminology-object-storage">
|
|
<title>Object storage</title>
|
|
<para>In OpenStack: Object Storage service (Swift)</para>
|
|
<para>Related concepts: Amazon S3, Rackspace Cloud Files, Ceph Storage</para>
|
|
<para>With <emphasis role="italic">object
|
|
storage</emphasis>, files are exposed through an
|
|
HTTP interface, typically with a REST API. All client
|
|
data access is done at the user level: the operating
|
|
system is unaware of the presence of the remote
|
|
storage system. In OpenStack, the Object Storage
|
|
service provides this type of functionality. Users
|
|
access and modify files by making HTTP requests.
|
|
Because the data access interface provided by an
|
|
object storage system is at a low level of
|
|
abstraction, people often build on top of object
|
|
storage to build file-based applications that provide
|
|
a higher level of abstraction. For example, the
|
|
OpenStack Image service can be configured to use the
|
|
Object Storage service as a backend. Another use for
|
|
object storage solutions is as a content delivery
|
|
network (CDN) for hosting static web content (e.g.,
|
|
images, and media files), since object storage already
|
|
provides an HTTP interface.</para>
|
|
</section>
|
|
<section xml:id="terminology-block-storage">
|
|
<title>Block storage (SAN)</title>
|
|
<para>In OpenStack: Block Storage service (Cinder)</para>
|
|
<para>Related concepts: Amazon Elastic Block Store (EBS),
|
|
Ceph RADOS Block Device (RBD), iSCSI</para>
|
|
<para>With <emphasis role="italic">block storage</emphasis>, files are exposed through a
|
|
low-level computer bus interface such as SCSI or ATA, that is accessible over the
|
|
network. Block storage is synonymous with SAN (storage area network). Clients access
|
|
data through the operating system at the device level: users access the data by
|
|
mounting the remote device in a similar manner to how they would mount a local,
|
|
physical disk (e.g., using the "mount" command in Linux). In OpenStack, the
|
|
<systemitem class="service">cinder-volume</systemitem> service that forms part of
|
|
the Compute service provides this type of functionality, and uses iSCSI to expose
|
|
remote data as a SCSI disk that is attached to the network.</para>
|
|
<para>Because the data is exposed as a physical device, the end-user is responsible for
|
|
creating partitions and formatting the exposed disk device. In addition, in
|
|
OpenStack Compute a device can only be attached to one server at a time, so block
|
|
storage cannot be used to share data across virtual machine instances
|
|
concurrently.</para>
|
|
</section>
|
|
<section xml:id="terminology-file-storage">
|
|
<title>File storage (NAS)</title>
|
|
<para>In OpenStack: none</para>
|
|
<para>Related concepts: NFS, Samba/CIFS, GlusterFS, Dropbox, Google Drive</para>
|
|
<para>With <emphasis role="italic">file storage</emphasis>, files are exposed through a
|
|
distributed file system protocol. Filesystem storage is synonymous with NAS (network
|
|
attached storage). Clients access data through the operating system at the file
|
|
system level: users access the data by mounting a remote file system. Examples of
|
|
file storage include NFS and GlusterFS. The operating system needs to have the
|
|
appropriate client software installed to be able to access the remote file system.</para>
|
|
<para>Currently, OpenStack Compute does not have any native support for this type of
|
|
file storage inside of an instance. However, there is a <link
|
|
xlink:href="http://gluster.org/community/documentation//index.php/OSConnect"
|
|
>Gluster storage connector for OpenStack</link> that enables the use of the
|
|
GlusterFS file system as a back-end for the Image service.</para>
|
|
</section>
|
|
</section>
|
|
</chapter>
|