Difference between revisions of "Murano/Incubation"
(→Programming language, required technology dependencies) |
(→Is project currently open sourced? What license?) |
||
Line 112: | Line 112: | ||
== Is project currently open sourced? What license? == | == Is project currently open sourced? What license? == | ||
− | + | Yes, Apache 2.0 | |
== Level of maturity of software and team == | == Level of maturity of software and team == |
Revision as of 13:08, 20 February 2014
Contents
- 1 Project codename
- 2 Trademarks
- 3 Summary
- 4 Parent Program name and PTL
- 5 Mission statement
- 6 Detailed Description
- 7 Basic roadmap
- 8 Location of project source code
- 9 Programming language, required technology dependencies
- 10 Is project currently open sourced? What license?
- 11 Level of maturity of software and team
- 12 Project developers qualifications
- 13 Infrastructure requirements (testing, etc)
- 14 Have all current contributors agreed to the OpenStack CLA?
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):
- 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:
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
TBD
Project developers qualifications
TBD
Infrastructure requirements (testing, etc)
TBD
Have all current contributors agreed to the OpenStack CLA?
Yes.