openstack-manuals/doc/install-guide/ch_terminology.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>