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.

Figure 1: Murano interacting with other 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
[...]

Figure 2: Applications in the Murano catalog of a private OpenStack installation.

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).

Figure 3: You can put together a complete environment in Murano with just a few mouse clicks – a complete web server with an underlying container infrastructure.

$ 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.