Jump to: navigation, search

Difference between revisions of "Murano/Incubation"

(Parent Program name and PTL)
(Detailed Description)
Line 54: Line 54:
 
*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.  
 
*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.  
  
 +
<br />
 
To address these scenarios Murano provides:
 
To address these scenarios Murano provides:
 
*Murano Application Catalog service which keeps Application definitions and manages dependencies between them.
 
*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.
 
*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.
 
*A toolset for generating rich user interfaces providing way to define complex environments built out of multiple interdependent applications and their resources.
 
  
 
== Basic roadmap ==
 
== Basic roadmap ==

Revision as of 13:02, 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

TBD

Programming language, required technology dependencies

TBD

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.