OpenStack release planning is a smooth process, and release manager Thierry Carrez has the reins firmly in hand. The development of OpenStack 2014.1, alias "Icehouse," progressed with very few glitches. OpenStack  [1] enjoys an extraordinarily good reputation within the FOSS developer, system administrator, and IT architect community because of its reliable release cycles. In the past two years, the OpenStack cloud platform has gained a reputation for being extremely reliable – with both the timeline and the quality of work. The Icehouse release is both a solid maintenance version and a motor for future innovation. What are the changes? Does the OpenStack cloud framework deliver what its developers promised? Read on for a closer look at the new version.

Trip to Oslo

One of the most important innovations in OpenStack is the Oslo Common Libraries Project [2], which has been around for some time but only truly became an integral part of the OpenStack project in recent months. Oslo's goal is to eliminate the often annoying redundancies in OpenStack source code – and prevent them in future.

OpenStack currently consists of several individual projects, such as the Glance virtual image repository, Nova controller, Cinder block storage, and other components that perform specific tasks. Because of mandatory project standards, however, many components need to continually re-implement individual functions themselves: RPC communication with various AMQP services is a good example. In the past, one OpenStack project often has adopted and modified source code from another  – which is bad for several reasons: A new release does not automatically ensure that improvements in one part of the source code filter down to the copies; a manual merge takes time and causes trouble. Additionally, copying source code among the various components unnecessarily bloats the code.

The problem is already known in virtually any programming language, and the solution is a library. Libraries provide a unified API, which other programs then use to incorporate key components into the code.

Oslo, which brings a library of frequently used Python routines to OpenStack, is truly a core project; in contrast to the other components in OpenStack, however, admins rarely have any direct dealings with Oslo modules. In Icehouse, the developers have extended and spruced up various Oslo modules; a complete list is available on the OpenStack wiki at [3]. Also, even if the project looks unspectacular at first glance, it has the potential to change the face of development in the OpenStack project in the long term.

Incidentally, the OpenStack developers are quite willing to look outside the box: If they find a specific functionality outside of OpenStack relevant, they publish the module outside the Oslo framework as a standalone Python module, thus giving other projects the possibility of benefiting from the development work at OpenStack. Once again, the OpenStack project shines as an F/LOSS flagship project.

Detail Work

Elsewhere in OpenStack, much has happened since the last release. In the past, the Glance image repository spoke only English. OpenStack developers had not spent a lot of time worrying about multilingualism. For seasoned admins who are non-native English speakers, dealing with English-only software is usually only a minor problem. End users, however, often find it hard to follow computer programs that speak another language. The call was for better localization, and this has now happened with Glance: The gettext module in Glance now supports localization to any language that gettext can handle. Other OpenStack components will soon follow this example and offer the ability to present logs and API service messages in other languages.

Cloud Block Manager

The OpenStack Nova compute controller also introduces some new features, of which the "Callback API" is probably the most significant. Thus far, the Nova API was mainly responsible for the functions that support starting or stopping a virtual machine. After the VM launch (Figure 1), Nova's work was done – or at least, Nova did not let admins communicate directly with their virtual systems or modify them after starting. For instance, if you wanted your virtual machine to have more than one network connection, or even if you wanted two network ports to reside on different private networks, you used to have to reboot.

Figure 1: Launching a virtual machine in OpenStack.

The Callback API solves this problem by allowing other components in OpenStack to retroactively change the configuration of a VM. Another benefit of this new feature is creating a snapshot of a VM with Cinder. On request from the admin, Nova informs Cinder then locks down the VM to avoid it becoming a "moving target." Once Cinder is finished, it sends a message to Nova, telling it to stop blocking. The Callback API shows OpenStack's trend toward increasingly integrating the individual components and making them more interactive. Icehouse is the first version of OpenStack to offer this feature.