The IT news is beginning to sound like a scene from the movie "Being John Malkovich" in which the hero undertakes a journey into himself and notices that every spoken sentence is replaced by "John Malkovich." In IT, every sentence is cloud, cloud, cloud.

And increasingly, "cloud" means the OpenStack cloud. The open cloud environment supported by the OpenStack project has become everybody's darling. But is the hype justified? This article takes a close look at one of the most interesting projects in the FOSS world.

Reality Check: OpenStack

OpenStack is not a monolithic program. In fact, the name OpenStack now designates a very comprehensive collection of components that join forces to take care of automation. The various OpenStack components each handle a specific part of the overall system. The OpenStack world defines the following automation tasks:

• User management
• Image Management
• Network management
• VM management
• Block storage management for VMs
• Cloud storage
• The front end to the user

Each of these tasks is assigned to an OpenStack component. Incidentally: Components in OpenStack always have two names: an official project name and a codename. The article uses the much more commonly used codenames to designate the various OpenStack components.

User Management: Keystone

For customers to be able to configure their services correctly within a cloud computing environment, the system must offer them a user management system. In OpenStack, Keystone [1] ensures that users can log in with their credentials.

Keystone doesn't just implement a simple system based on users and passwords; it also provides a granular schema for assigning permissions. At the top are the tenants that typically represent the corporate level in the cloud environment: the cloud provider's customers. Then there are the users, each of whom is a member of a tenant; different users may well have different rights. For instance, the company's boss might be authorized to start or stop VMs or to assign new admins, while the lowly sys admin can only start or stop virtual machines. Keystone lets you build this kind of schema – and for multiple tenants.

Keystone is also responsible for internal communication with other OpenStack services. For one OpenStack service to be able to talk to another, it must first authenticate with Keystone. Keystone middleware exists for this purpose. The middleware is a kind of Python plugin that any internal or external component can use to safely handle Keystone authentication. Speaking of Python, like all other OpenStack services, Keystone is 100 percent written in Python.

For the cloud to succeed, much communication takes place between the individual OpenStack components. But, because clouds need to scale, it would be very impractical to use static IPs for this communication. Thus, Keystone maintains a kind of phone book within the OpenStack cloud: The endpoint directory lists OpenStack services and where to reach them. If a service wants to talk to another service, it simply asks Keystone and receives the desired information in almost no time. If the address of a service changes later, the admin only changes the address in Keystone and does not have to change all configuration files for each service on each host.

Image Management: Glance

Cloud offerings designed for use in the web interface must meet one key requirement: Barriers must be low. The customer must be able to start a new VM at the press of a button; otherwise, the entire environment is of no use to the customer.

It is hardly reasonable to expect the customer to manually handle the installation of an operating system on the VM – often enough, customers will not have the knowledge necessary to install the virtual machine. The admin is naturally not interested in taking on the task manually.

Glance [2] provides a solution to the problem: The admin uses Glance in a cloud environment to create prebuilt images, which are then selected by the user as required for new VMs. The admin only needs to do the work once when setting up the image, and the subject of operating systems does not worry the customer.

Under the hood, Glance consists of two dashboard services, an API, and a tool that takes care of image management (Figure 1). This classification is often found in a slightly modified form throughout OpenStack. Keystone is basically nothing more than an HTTP-based API that is addressed using the ReSTful principle.

Figure 1: Via the dashboard, users can gain access to the images that are stored in Glance – simply click and choose.

Glance is one of the more inconspicuous OpenStack components, and admins very rarely have to use it after the first install. It supports multiple image formats, including, of course, the KVM Qcow2 format, VMware's VMDK images, but also Microsoft's VDI format from Hyper-V. Admins can easily convert existing systems into Glance-compatible images (raw images).

Glance has its field day when users need to start a new VM: The service copies the image for this VM to the hypervisor host on which the VM runs locally. Of course, for administrators, this means that Glance images should not be too large; otherwise, it takes an eternity until the image reaches the hypervisor. Incidentally, many distributions offer ready-made Glance images: For example, Ubuntu comes with UEC images [3].