Apart from Ubuntu, no other project holds so true to a fixed release cycle as OpenStack. In parallel with Canonical, the developers launch each new version in April and October. This April was no different: Recently, OpenStack 2013.1, known as Grizzly, became available for downloading. As with the previous releases, much has changed this time around. For administrators of existing cloud deployments, the question arises as to whether an upgrade is worthwhile and whether it is easy to handle. So far, OpenStack has not exactly crowned itself with glory when it comes to updates.

Up to now, the only reasonable advice to OpenStack admins was: Do not try to update one OpenStack version to another. The first tagged with the "Enterprise Ready" label, OpenStack Essex, became available in April 2012. At that time, the developers promised to pay more attention to API compatibility between old and new versions in the future – with very modest success: Updating from Essex to its successor Folsom was complicated to impossible.

API Stability

Between Folsom and Grizzly, the developers seem to have done their homework: Instead of changing existing APIs, they added additional APIs and gave these higher version numbers.

This approach becomes clear in the case of Keystone, the authentication component: In addition to the API v2 which already existed in Folsom, Keystone now has an API 3.0 that works in parallel with the old API so that existing installations do not require reconfiguration.

The developers promise that the old API will remain at least until the next release, that is, the I-release (as with Ubuntu, all OpenStack releases are given code names that follow the alphabet, e.g., the successor of Grizzly is Havana).

That said, functions of the 3.0 API cannot be harnessed from within the 2.0 API. In a test of the previous version, migrating a Folsom Keystone to a Grizzly Keystone worked well, although the user base I migrated was fairly small. All told, the update seemed to be reliable, although admins would do well to test the migration under laboratory conditions before converting a production system.

New Components

Grizzly thus offers some update potential, but is the update worthwhile? The answer to this question might lie in the two new additions to the OpenStack core components family: Ceilometer and Heat.

Ceilometer is Open Stack's eagerly awaited statistics component. However, Ceilometer is not just designed to collect statistical data in OpenStack and generate colorful charts. Instead, the developers see their creation in the role of a billing system. Ceilometer then takes the place of the usage statistics already contained in the Nova computing component, which were very rudimentary.

The highlight of Ceilometer is that it is said to be capable of making its data available to any number of users. Theoretically, it can thus be used as a data source for an industrial billing system and as a source for cloud monitoring. One client (or in Ceilometer-speak, "consumer") is BillingStack, which is a separate billing system for OpenStack that allows billing of OpenStack services on the basis of user consumption. The Ceilometer site does not list any other consumers to date, but the environment only became part of Open Stack in Grizzly as an incubated project. You can look forward to many more consumers soon.

OpenStack welcomes another newcomer to Grizzly: Heat has also made the grade as an incubated project. Heat refers to itself as an orchestration suite, although it does not enter into direct competition with other solutions such as Puppet or Chef. Heat is strictly specific to OpenStack: Using a single file – a template – Heat allows users to build virtual machines from scratch and connect them with one another. A template could be, for example, "Web Server Cluster," that would automatically create a web server farm.

Heat includes features of practical use, such as high availability and basic monitoring. Moreover, OpenStack Heat supports the Amazon AWS Cloud Formation format to allow inter-VM orchestration in its own cloud. Ultimately, Heat is primarily a tool that will help admins with automation, which means it fits in very well with OpenStack, which names total automation as its ultimate principle.

New Features in Keystone

The established components of OpenStack impress in Grizzly with a number of great new features. Keystone, as a central ID component, leads the way with support for Active Directory, which, after LDAP, is the second most widely used method for managing your users centrally.

The aforementioned API also has some new features. For example, tenants are now known as projects. Anyone who knows the history of OpenStack will be experiencing déjà vu here, because Nova had projects that were then renamed to tenants. Security-conscious people will be happy for the opportunity to use multiphase authentication in Keystone.