Going Native with OpenStack Centric Applications: Murano

Following on our previous discussion surveying the projects supporting applications within OpenStack, let’s continue our review with an in-depth look at the OpenStack-native Application Catalog: Murano, currently an incubation status project, having seen its functionality and core services integration advanced over the past few OpenStack releases.

What is it?

An application catalog developed by Mirantis, HP and others (now including Cisco), that allows application developers and cloud administrators to publish applications in a categorized catalog to be perused and deployed by application consumers. The selection of applications available within the catalog is intended to be that of released versions (ready-state) of applications (cloud-native or enterprise-architected), not application versions that are mid-development. Ideally, these are applications ready to be consumed and run by application users.

Functionality Highlights


  1. Supports Windows and Linux applications
  2. Leverages HOT templates for application definition
  3. Controls Heat stack creation and updates processes
  4. Track application properties and dependencies
  5. Defines provisioning workflow definitions and executes them
  6. Introduces “Application” and “Environment” constructs
  7. Provides UI for application topology visualization
  8. Control lifecycle of a deployed application
  9. Allows simple management of access to an application
  10. Compose an environment from multiple application components
  11. Out of the Box Cataloged Applications
    • 16 sample applications available now
    • 6 production-grade applications の Mirantis OpenStack Express**
  12. Multiple application formats supported:
    • HOT Templates
    • MuranoPL
  13. Vision to support
    • Other application model formats:
    • Parallels APS format
    • TOSCA format
    • Pricing; billing system integration

User Personas & Capabilities

As an application catalog, Murano, primarily focuses on three user personas, the Cloud Administrator, Application Consumer and Application Publisher receiving the most emphasis upfront in the development of this project.

Application Consumer

The Application Consumer selects and deploys instances of applications into environments they define. The Application Consumer also*

Application Publisher

The Application Publisher creates application definitions (packages) that are imported as entries into the application catalog for perusal by Application Consumers. The Application Publisher also*

Cloud Administrator

The Cloud Administrator is responsible for running the application catalog and providing stable infrastructure upon which to deploy and run applications. The Cloud Administrator also*

Application Packaging Process

Currently, Murano applications may be packaged using two different formats to describe the application – the MuranoPL or a HOT template. There’s roadmap to support addition application description formats. While these two methodologies vary in terms of how the orchestration is performed during provisioning of an instance of the app, their are common attributes (catalog metadata) like an application display name, logo, description, author, tags. For those familiar with other domain-specific languages of other popular configuration management frameworks, the MuranoPL is of little challenge to pick up (you may lean into use Bash or Powershell if more comfortable) or you may opt to use SoftwareConfig and SoftwareDeploy of HOT.

Architectural Overview & Core Services Integration

See the “Murano Architectural Overview” diagram for a visual representation of how Murano is tightly integrated with core OpenStack services. It’s relationship to existing core services breaks down as follows:



Murano and Containers

Murano inherently supports Docker containers by relying upon existing OpenStack components for container integration and orchestration. This means that there are no considerations to be accounted for within the MuranoPL to describe the application package to support containers. Similarly, when using Heat templates at the core of the application package, only reference to Docker resources and images is needed to support container orchestration by Heat. There are different ways of using Docker in OpenStack via Murano:

1) Heat template can use Heat::Docker

2) Heat template can use Nova::Docker

3) Not recommended – Use Heat resource to create a VM with Dockerénside and boot an image file to the VM with docker run.

Murano as a Southbound Catalog

Murano has two different northbound APIs to expose access to applications in the catalog – REST and AMQP (Services Broker). Within the Juno release, the Services Broker has only been prototyped. It’s scheduled to be fully-implemented in Kilo. While other use cases may exist, the primary use case for these northbound API revolves around allowing northbound catalogs to access and expose OpenStack-native applications.

The Services Broker supports CRUD and binds service with your application. A proof of concept has been completed to integrate Cloud Foundry with Murano via the Service Broker. When CloudFoundry is integrated to Murano, CloudFoundry users see and order Murano applications in CloudFoundry.

Using the REST API, Murano may be integrated as a southbound application catalog to expose OpenStack-native applications as SaaS application profiles available for users of a northbound catalog. Users benefit from existing services offered on top of OpenStack. This enables application components to be split across infrastructure (having application components deployed into different infrastructures).

Kilo Roadmap

While subject to change, based on Kilo design summit discussions this week, the project team aims to bite off the following capabilities before the next release in May.

From http://blog.gingergeek.com/2014/11/going-native-with-openstack-centric-applications-murano/


comments powered by Disqus