House of Cool

Feature Balancing: Heat and Ceilometer

The Heat orchestration service was first introduced in the previous version of OpenStack; and while many observers point to a certain degree of immaturity in the first version, the service has made some great advances in Icehouse. The developers have added tweaks in every possible nook and cranny: You can set a "service" type for a template. Authors of Heat templates have the choice to offer generic templates or stipulate from the outset that a template is designed for use with a specific service. For OpenStack, this option is of great importance because more and more components are offering specific services: Trove is responsible for DBaaS, and Sahara provides Hadoop as a service. Ready-made templates make it easier for admins to use Heat effectively.

A template interface for Heat dynamically expands Heat's features to reflect the customer's needs, with customers definitely having the option of installing plugins. The core of Heat, the engine, provides only a few basic functions, according to the developer's unanimous decision. These functions include starting or stopping VM environments ("stacks" – Figure  3) and automating the network configuration for virtual systems. If you want to automate other functions, use the Heat plugin function.

Figure 3: Setting up a stack.

Some template functions have also been added to the Heat core; the "software configuration" framework for Heat templates will, in the future, use a standardized format to define the configuration of individual services that run on Heat VMs. The design decision suggests that the "small number of basic functions" in the eyes of the developers involved with Heat will clearly go beyond merely starting and stopping VMs. An interesting question in the future will be where the limits lie. What features are generic enough to belong to the Heat core, and what features need to be swapped out into plugins?

The heat developers describe the Adopt feature in a somewhat confusing way in the changelog: In Icehouse, it will be possible for a user to relinquish control over a running Heat stack, thus allowing another user to take over the stack. This feature is designed to simplify the management of VMs.

In the Ceilometer camp, most of the changes that took place will not directly affect users. Granted, Ceilometer runs in the background and acts as an accountant in the cloud; users only have contact with the software via the dashboard. Despite this issue, the developers still introduced some interesting features in Icehouse. For example, Ceilometer understands performance data from VMware's VCenter. Those who use OpenStack clouds with VMware hypervisors now have access to a full-fledged metering application with Ceilometer in Icehouse. If you query the Ceilometer database from your own app, you will have better filter options in the future to determine which results to display. Ceilometer also has a new filter parser that can handle complex regular expressions in Icehouse.

Off the Beaten Track: Swift

The latest version of Swift also offers some exciting features: the Object Replicator, which ensures that binary objects within the Swift cluster are copied back and forth and thus redundantly maintained, has been rewritten and is now faster and more reliable.

When this issue went to press, it was not clear whether the Storage Policies feature would make the cut-off for Swift at the last minute. The aim of this functionality is a tiering-like configuration of content that distributes different parameters within the cluster without making it more complex to call them. Even if the feature did not make it into the Icehouse version of Swift, there is nothing to worry about: Swift releases appear very regularly, usually after an OpenStack release, and during the regular OpenStack release cycle. No need to wait another six months.

New Kid on the Block: Trove

A milestone for any OpenStack subproject is when it officially becomes part of the OpenStack core and OpenStack commits to providing long-term care for it. The Trove database-as-a-service makes its debut in the core release. Through its own API, Trove accepts commands for new VMs and, after processing the parameters of the API command, uses Nova to start a separate database instance, which then comes up with a complete, ready-to-use database. In fact, Trove is the first OpenStack service that operates a helper in the virtual machine itself: trove-guestagent fields commands from Trove and then configures the database on the VM to match the user's specifications. Right now, the service only supports MySQL, but because it has a generic framework in the background, you can safely assume that support for other databases will soon follow.