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.

OpenStack version names

Release name	Release date	OpenStack version number for Block Storage, Compute, Identity, Image, and Networking	OpenStack Object Storage version number
Havana	October 2013	2013.3	unknown
Grizzly	April 2013	2013.1	1.7.6
Folsom	October 2012	2012.2	1.7.2
Essex	April 2012	2012.1	1.4.8
Diablo	October 2011	2011.3	1.4.3
Cactus	April 2011	2011.2	1.3.0
Bexar	March 2011	2011.1	1.2.0
Austin	October 2010	0.9.0	1.0.0

Beginning with the Cactus release, OpenStack adopted a six month release schedule. The Havana release is scheduled for October 2013.

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:

Code names

Service name	Code name
Identity	Keystone
Compute	Nova
Image	Glance
Dashboard	Horizon
Object Storage	Swift
Volumes	Cinder
Networking	Neutron

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 keystone.conf. 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:

Code names

Service name	Code name
Metering	Ceilometer
Orchestration	Heat

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. OpenStack services are implemented by multiple Linux services. For example, nova-compute and nova-scheduler 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). 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., glance-api).

Many cloud computing use cases require persistent remote storage. Storage solutions are often divided into three categories: object storage, block storage, and file storage. Note that some storage solutions support multiple categories. For example, NexentaStor supports both block storage and file storage (with announcements for future support for object storage), GlusterFS supports file storage and object storage, and Ceph Storage supports object storage, block storage, and file storage.

In OpenStack: Object Storage service (Swift) Related concepts: Amazon S3, Rackspace Cloud Files, Ceph Storage With object storage, 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.

In OpenStack: Block Storage service (Cinder) Related concepts: Amazon Elastic Block Store (EBS), Ceph RADOS Block Device (RBD), iSCSI With block storage, 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 cinder-volume 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. 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.

In OpenStack: none Related concepts: NFS, Samba/CIFS, GlusterFS, Dropbox, Google Drive With file storage, 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. Currently, OpenStack Compute does not have any native support for this type of file storage inside of an instance. However, there is a Gluster storage connector for OpenStack that enables the use of the GlusterFS file system as a back-end for the Image service.