Ready-Made

Several projects now exist under the patronage of OpenStack or the OpenStack Foundation. What started out as quite a small project in 2010 with Nova and Swift has become an extensive collection of various as-a-service modules. Like OpenStack itself, requirements and expectations of OpenStack's users have also grown.

From a data center perspective, it might be sufficient to be able to provision servers, networks, and storage quickly and elegantly. Although it is possible for cloud providers to earn money this way, for most others, the infrastructure is only the beginning. Applications need to run on an OpenStack machine with a configuration appropriate to their actual business needs. Infrastructure alone is not enough. In contrast, the typical case is two-or three-tier applications with dependencies between the individual components and often additional requirements for the associated network.

Complete Collection

Suppose someone is looking for new clothes. That person might need a shirt, vest, jacket, and pants. In this analogy, OpenStack would be equivalent to a shopping mall. Buyers visit individual shops and choose what they want. In doing so, they need to make sure that the items match. Would it not be much easier to choose a pre-assembled outfit from a catalog?

The OpenStack Murano [1] project is a catalog of sorts – but for applications. Roughly speaking, the project provides interfaces for installing and managing a complete application environment in an OpenStack cloud. Murano does not exactly reinvent the wheel; instead, it draws on existing projects.

Heat and Mistral, for example, are used for orchestration and work processes. Murano sees itself as an integrator that merges the existing pieces of the puzzle into one image. Figure 1 shows an abstract view of the interaction between OpenStack components.

Murano has evolved since its launch in 2013 and is now much more than just a catalog. For example, it manages the entire lifecycle of an application, including jobs such as automatic scaling, high availability, or even just plain old backups. A look at the plans for the future [2] gives an idea that a lot more is still to come.

History: How It All Began

The beginnings of the Murano project date back to around February 2013. Interestingly, the project started off life on Windows and its directory service, Active Directory. The driving force behind the application catalog was Mirantis [3], one of the founding members of the OpenStack Foundation. A simple analysis of the software contributions to Murano shows that at least half of the approximately 80 developers come from this company. However, the project only really began to shine with the release of OpenStack Juno.

If you can't wait to take a look at the catalog at this point, you will find the necessary instructions and tips in the "First Steps" box.

$ git clone https://git.openstack.org/openstack-dev/devstack
[...]
$ git clone https://git.openstack.org/openstack/murano
[...]
$ export DEVSTACK_DIR=`pwd`/devstack/
$ cd murano/contrib/devstack/
$ cp lib/murano ${DEVSTACK_DIR}/lib
$ cp lib/murano-dashboard ${DEVSTACK_DIR}/lib
$ cp extras.d/70-murano.sh ${DEVSTACK_DIR}/extras.d
$ cd $DEVSTACK_DIR
$ vi local.conf
[...]
$ cat local.conf
[[local|localrc]]
ADMIN_PASSWORD=Password
DATABASE_PASSWORD=$ADMIN_PASSWORD
RABBIT_PASSWORD=$ADMIN_PASSWORD
SERVICE_PASSWORD=$ADMIN_PASSWORD
SERVICE_TOKEN=b670a556-36a3-37c3-a5d2-f712f8080d50
enable_service heat h-api h-api-cfn h-api-cw h-eng
enable_service murano murano-api murano-engine
$ sudo ./tools/create-stack-user.sh
[...]
$ sudo cp -a /root/devstack /o pt/stack/
$ sudo chown -R stack:stack /opt/stack/
$ sudo su - stack
$ cd devstack
$ ./stack.sh
[...]

Who's Talking to Whom and Why?

Figure 1 shows Murano's interactions with various OpenStack components. There are two processes active in the background: murano-api and murano-engine. The name implies that murano-api is the interface to the outside. A native Murano client (or other OpenStack components) establishes contact via this daemon. It passes on the information to the other process – the engine – which is responsible for the actual work.

The first step is then to generate an environment. Murano essentially summarizes the applications to be installed here with a few infrastructure details for the underlying virtual server. This can include details about the variant used for the guest, network, server name, or availability zone. In other words, the environment specifies the topology of the service to be installed. Each of these structures is given a name for referencing purposes.

The Murano machine analyzes the environment information and checks that all the necessary components are available and accessible. If users want to discover more about the environment, using the graphical interface is recommended because the command line is not particularly communicative here (Listing 2) – much in contrast to access via Horizon (Figure 3).

$ murano environment-list
+----------------------------------+------------+---------------------+---------------------+
| ID                               | Name       | Created             | Updated             |
+----------------------------------+------------+---------------------+---------------------+
| 1160f3d830cd4aaf8ea53bf42d4bd8f9 | DockerTest | 2015-09-01T05:20:20 | 2015-09-01T05:20:20 |
+----------------------------------+------------+---------------------+---------------------+
$ murano environment-show 1160f3d830cd4aaf8ea53bf42d4bd8f9
+------------+----------------------------------+
| Property   | Value                            |
+------------+----------------------------------+
| created    | 2015-09-01T05:20:20              |
| id         | 1160f3d830cd4aaf8ea53bf42d4bd8f9 |
| name       | DockerTest                       |
| networking | {}                               |
| services   | []                               |
| status     | pending                          |
| tenant_id  | 55273dedb2be476c812f0bc3f953f2cf |
| updated    | 2015-09-01T05:20:20              |
| version    | 0                                |
+------------+----------------------------------+
$

If everything is all right, Murano then contacts the necessary OpenStack modules to provide the corresponding components, such as Neutron for network components. The next step is for Murano to create an orchestration template – known as a Heat template in OpenStack-speak. The template serves as a framework for the subsequent steps.

You have two options here. The Murano approach would be to install agent software [9] [10] on the virtual server. This then takes care of other unfinished tasks. Glance images with these agents can be found online [11]. Alternatively, you can take the plain vanilla Heat route. The next steps are cued completely by the definitions within the OpenStack orchestration software.

One way or another, users have a fully installed and configured application available to them in the end. The last step involves sending feedback to the API daemon, which passes the success or failure message on to the outside.

Packetize It Yourself

Readers might now be wondering in what marvelous way the components' dependencies or the parameters to be configured come into play to create a working environment. The installation sequence of the applications involved also plays an important role in many cases. The magic is hidden in the Murano packages for the applications involved, which contain the recipes with all their ingredients, including cross-references to other instructions.

As a first step, you can download ready-made packages from the community catalog [12] and integrate them into your own OpenStack installation. Preparing your own package, of course, gives you an in-depth look behind the scenes. In principle, the required procedure is documented [13]-[15], but the documentation is not easy to read. The instructions contain several cross-references, meaning you often need to switch back and forth. You also need to learn the Murano programming language (MuranoPL) [16], which comprises the markup languages YAML [17] and YAQL [18].

There are two approaches to building packages. The variant that is initially easier relies on a Heat template as a base [19]. Entering

murano package-create --template </path/to/Heat-template>

generates a ZIP archive that can be integrated using

murano package-import </path/to/ZIP-file>

The users' control methods are pretty limited here. Only a few additional options are available for the package-create subcommand and the configurations in the Heat template itself.

Putting together a Murano package manually might require more overhead, but manual packages can also be easily customized to suit your own needs. The essential components are a general description of the application and the installation instructions. The latter contains references to scripts to be used, MuranoPL classes, and possibly user dialogs for querying configuration settings. The description is made in the previously mentioned YAML/YAQL format. A specific directory structure is used for storing the various files. I posted a simple example on my GitHub page [20].

This Side of the Horizon and Beyond

Murano currently has some very useful features. The standout feature is the ability to install complete applications including dependencies and additional definitions at the touch of a button. In one fell swoop, OpenStack gives administrators more than just an infrastructure in which users still have much work to complete before meaningful business becomes possible.

Murano takes this a step further: From now on, Murano administrators can define application actions. Using these actions, administrators can implement features like automatic scaling, high availability, or backups [21].

A quick look at the roadmap for the next version [2] shows that the project still has plenty of potential for improvement. The only bad news is that Mirantis is the only highly visible supporter thus far. More cooperation from other members of the OpenStack family would be very desirable here. Murano can therefore be viewed as a big step in the right direction, conveniently linking applications and infrastructure.