Jump to: navigation, search

Difference between revisions of "Murano/Incubation"

(Programming language, required technology dependencies)
(Programming language, required technology dependencies)
Line 109: Line 109:
 
== Programming language, required technology dependencies ==
 
== Programming language, required technology dependencies ==
 
* Language: mostly Python, Windows VM agent is written on C# for better performance on Windows guest OS
 
* Language: mostly Python, Windows VM agent is written on C# for better performance on Windows guest OS
* Dependencies:  
+
* Dependencies: pbr, eventlet, anyjson, jsonpath, netaddr, jsonschema, PyYAML, YAQL
pbr, eventlet, anyjson, jsonpath, netaddr, jsonschema, PyYAML, YAQL
 
  
 
== Is project currently open sourced? What license? ==
 
== Is project currently open sourced? What license? ==

Revision as of 13:08, 20 February 2014

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.

Basic roadmap

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:

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

Non-essential repositories include:

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?

TBD

Level of maturity of software and team

TBD

Project developers qualifications

TBD

Infrastructure requirements (testing, etc)

TBD

Have all current contributors agreed to the OpenStack CLA?

Yes.