Murano/Incubation

Incubation Status
The incubation requirements checklist for Murano may be found here

Project codename
Murano

Trademarks
no registered IT-trademarks known

Summary
Application Catalog for publishing, sharing, deploying and managing the lifecycle of third-party applications and software services on top of OpenStack clouds.

Parent Program name and PTL
TBD - seeking an advice of TC on the proper governance model for the project

Possible options:

New program to reflect the extensive scope
Pros:
 * Introduce a platform-layer program of OpenStack (other programs target Infrastructure-layer)


 * Does not distract existing teams

Cons:
 * Potential mission overlap with Orchestration program (both claim to manage application lifecycle, yet from different points of view)

Orchestration program
Pros:
 * Existing established program.
 * Fits to orchestration mission in sense of application lifecycle management.
 * Allows a better alignment between Heat and Murano in deployment area

Cons:
 * Introduces additional burden on PTL and existing core team
 * Disrupts Orchestration mission with catalog related features which are not a part of orchestration process
 * Mixes infrastructure management and higher level platform features

Murano fits to Catalog program which can be an extension of existing Glance
Pros:
 * Might fit updated Glance mission in catalog and marketplace areas.
 * Allows a better alignment between Murano and Glance in artifact storage and metadata catalog areas

Cons:
 * Extends current Glance mission from image oriented to general metadata storage and catalog
 * Introduces additional burden on PTL and existing core team

Mission statement
To build a catalog service for distribution, management and consumption of third party applications and their aggregation on top of OpenStack cloud environments.

Detailed Description
The Murano project allows to publish and manage applications and services which may be then provisioned by the end-users of OpenStack clouds.


 * From publisher’s point of view Murano provides a set of APIs to define and upload the definitions of applications structure. These definitions, being grouped in a so-called “application packages” are stored in the catalog, annotated with descriptive fields, tags, infrastructure requirements, external dependencies for integration with other applications etc.
 * Also, published application may define various options to control the licensing and distribution, including the usage limits and some billing metrics.


 * From end-user’s perspective the catalog provides a way to find specific application by using navigation, search and filtering among different applications listed in application catalog. Catalog stores application with its meta information which helps the end-user to choose the application properly according to their usage scenarios, business needs and available cloud environment.
 * Once the user has chosen the application, it can be deployed in the cloud infrastructure operated by this user. Murano provides a way to compose the environments out of multiple applications and required resources, dynamically managing their interdependencies.


 * Third group of Murano users are the cloud administrators. They manage the application catalog by reviewing and approving the submitted application packages, specifying the access rights and the visibility for approved packages, and - according to specific, configurable policies - approving the environment composed by the users for the deployment.

To address these scenarios Murano provides:
 * Murano Application Catalog service which keeps Application definitions and manages dependencies between them.
 * Murano engine which organizes workflow execution and integrates with Heat deployment engine and other core openstack services.
 * A toolset for generating rich user interfaces providing way to define complex environments built out of multiple interdependent applications and their resources.

Current release (0.4):

 * Deployment engine build on top of Heat (generates Heat templates based on the environment state and user input) and other components (discovers available cloud components, coordinated VM-side scripts execution etc)
 * XML-based language for deployment workflow definition (defines a set of environment transformations needed to deploy a set of applications
 * VM-side client application for post-deployment software configuration
 * Rich UI for wizard-like environment-definition
 * Simple catalog of application and service definitions
 * REST API for for environment definitions and deployments
 * REST API for catalog browsing and maintenance
 * Full Havana support (integration with Heat, Neutron, Horizon)
 * Set of example services for composing both Windows- and Linux-based environments

Next major release (0.5, planned for release before the IceHouse release):

 * New application definition markup for easier and better-structured definition of applications’ metadata, allowing object-oriented event-driven approach to their deployments.
 * New storage of Application Metadata Packages, with improved categorization capabilities, per-tenant isolation and data sharing
 * Improved UI for dynamic environment configuration
 * Per-application usage reports and statistics

Future development:

 * Support of Heat Software Config for post-deployment software configuration where applicable
 * Storing of Application Packages in the Unified Metadata Storage (Glance or some evolution of Glance)
 * Ceilometer support for advanced usage statistics to collect data for elastic billing scenarios
 * Mistral usage for Workflow automation
 * Trove support for Database provisioning

Location of project source code
Murano source code is split into several git repositories, all hosted on stackforge. The primary repositories are:
 * Murano REST API
 * Murano Deployment Orchestration Engine
 * Murano Application Metadata Repository

The project was initially split into these three repositories in an attempt to have a “one module - one repository” approach. This approach turned to be eventually wrong and does not follow usual openstack practices. That is why it is planned to merge this three repositories into a single one in future.

Additional repositories:
 * Python bindings for Murano APIs (two repos to be merged into a single one when the primary API repositories are merged):
 * for main Murano API
 * for Murano Application Metadata Repository


 * Openstack Dashboard plugin
 * VM side agent applications (both for Windows and Linux Guest OS’)
 * Extra stuff common for two or more Murano modules

Non-essential repositories include:
 * Murano documentation
 * Murano Integration tests
 * Murano deployment scripts

Programming language, required technology dependencies

 * Language: mostly Python, Windows VM agent is written on C# for better performance on Windows guest OS
 * Dependencies: pbr, eventlet, anyjson, jsonpath, netaddr, jsonschema, PyYAML, YAQL

Is project currently open sourced? What license?
Yes, Apache 2.0

Level of maturity of software and team
The project has been in active development for more than 12 months, being initially designed as Windows-DataCenter-as-a-service, then - by customers’ requests - rescoped as a general-purpose tool for complex environment deployments, and finally finding its mission as an Application Catalog for OpenStack. The team members have been working together for at least 6 month.

Project developers qualifications

 * Stanislav Lagun (stanlagun on irc) is a Principal Software Engineer at Mirantis. He is involved in Murano project since its beginning. Stan made major contribution to core part of Murano and he participates in general architecture discussions of Murano.
 * Alexander Tivelkov (ativelkov on irc) is a Principal Software Engineer at Mirantis. Alexander made major contribution to core part of Murano and he participates in general architecture discussions of Murano.
 * Sergey Melikyan (sergmelikyan on irc) is a Senior Software Engineer at Mirantis. He is involved in Murano project since its beginning. Sergey made major contribution to core part of Murano.
 * Ekaterina Fedorova (katyafervent on irc) is a Senior Software Engineer at Mirantis. Ekaterina made major contribution to Web UI part of Murano and Murano Metadata Repository component.
 * Timur Sufiev (tsufiev on irc) is a Software Engineer at Mirantis. Timur made major contribution to Web UI part of Murano (including Dynamic UI implementation) and Murano Metadata Repository component. He is Dynamic UI feature owner.
 * Dmitry Teselkin (dteselkin on irc) is a Senior Deployment Engineer at Mirantis. He is involved in Murano project since its beginning. Dmitry made major contribution to core part of Murano and setup scripts for Murano.
 * Igor Yozhikov (IgorYozhikov on irc) is a Senior Deployment Engineer at Mirantis. Igor Yozhikov made major contribution to support Linux-based Murano services, and setup scripts for Murano.
 * Timur Nurlygayanov (tnurlygayanov on irc) is a Senior Quality Assurance Engineer at Mirantis. He is involved in Murano project since its beginning. He is a QA Lead on Murano project and he tracks all Murano-related activities: review all commits, bugs and blueprints for Murano. Timur made major contributions to UI part of Murano and automated tests for Murano.
 * Anastasia Kuznetsova (akuznetsova on irc) is a Quality Assurance Engineer at Mirantis. Anastasia made major contribution to automated tests for Murano Web UI.
 * Sergey Murashov (smurashov on irc) is a Quality Assurance Engineer at Mirantis. Sergey made major contribution to tempest automated tests for Murano.

Infrastructure requirements (testing, etc)
All our code/reviews and bugs/specs are hosted at OpenStack Gerrit and Launchpad correspondingly. Unit tests and all flake8/hacking checks are run at OpenStack Jenkins and we have integration tests running at our own Jenkins server for each patch set. We hope that we’ll move our integration tests to the OpenStack infrastructure.

Have all current contributors agreed to the OpenStack CLA?
Yes.