Difference between revisions of "Murano/Documentation/How to create application package"
(→Step2. Prepare MuranoPL class definitions) |
(→Composing application package manual) |
||
(22 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
=Composing application package manual= | =Composing application package manual= | ||
− | Murano is Application catalog that supports types of applications. | + | Murano is Application catalog that supports types of applications. This document intends to make composing application packages easily. |
− | This document intends to make composing application packages easily. | ||
− | === | + | ===Step 1. Prepare Execution Plans=== |
An ''Execution Plan'' is a set of metadata that describes the installation process of an application in a virtual machine. | An ''Execution Plan'' is a set of metadata that describes the installation process of an application in a virtual machine. | ||
It's a minimal unit of execution that can be triggered in Murano Workflows and should be understandable by Murano agent. From ''Execution plans'' any script can be triggered. | It's a minimal unit of execution that can be triggered in Murano Workflows and should be understandable by Murano agent. From ''Execution plans'' any script can be triggered. | ||
Line 13: | Line 12: | ||
* '''Body''' - Python statement, should start with | symbol | * '''Body''' - Python statement, should start with | symbol | ||
* '''Scripts''' - dictionary that maps script names to script definitions. | * '''Scripts''' - dictionary that maps script names to script definitions. | ||
− | :Scripts are the building blocks of Execution Plans and they may be executed as a whole (like a single piece of code), expose some functions that can be independently called in | + | :Scripts are the building blocks of Execution Plans and they may be executed as a whole (like a single piece of code), expose some functions that can be independently called in scripts. This depends on Deployment Platform and Executor capabilities. One script can be defined with the following properties: |
:* '''Type:''' Deployment Platform name that script is targeted to. | :* '''Type:''' Deployment Platform name that script is targeted to. | ||
:* '''Version:''' optional minimum version of deployment platform/executor required by the script. | :* '''Version:''' optional minimum version of deployment platform/executor required by the script. | ||
− | :* '''EntryPoint:''' relative path to the file that contains | + | :* '''EntryPoint:''' relative path to the file that contains a script entry point |
− | :* '''Files | + | :* '''Files:''' This is an optional array of additional files required for the script. Use ''<>'' to specify a relative path to the file. The root directory is ''Resource/scripts''. |
:* '''Options:''' an optional argument of type contains additional options | :* '''Options:''' an optional argument of type contains additional options | ||
− | ''Example'' | + | ''Example DeployTelnet.template'' |
FormatVersion: 2.0.0 | FormatVersion: 2.0.0 | ||
Version: 1.0.0 | Version: 1.0.0 | ||
Line 26: | Line 25: | ||
Parameters: | Parameters: | ||
appName: $appName | appName: $appName | ||
− | |||
Body: | | Body: | | ||
return deploy(args.appName).stdout | return deploy(args.appName).stdout | ||
− | |||
Scripts: | Scripts: | ||
deploy: | deploy: | ||
Line 36: | Line 33: | ||
EntryPoint: deployTelnet.sh | EntryPoint: deployTelnet.sh | ||
Files: | Files: | ||
− | - | + | - installer.sh |
− | - | + | - common.sh |
Options: | Options: | ||
captureStdout: true | captureStdout: true | ||
captureStderr: false | captureStderr: false | ||
− | === | + | ===Step 2. Prepare MuranoPL class definitions=== |
MuranoPL classes control application deployment workflow execution. Full information about MuranoPL classes can be found [https://wiki.openstack.org/wiki/Murano/DSL/Blueprint#Common_class_structure here]. | MuranoPL classes control application deployment workflow execution. Full information about MuranoPL classes can be found [https://wiki.openstack.org/wiki/Murano/DSL/Blueprint#Common_class_structure here]. | ||
+ | |||
''Example'' | ''Example'' | ||
<syntaxhighlight lang="yaml"> | <syntaxhighlight lang="yaml"> | ||
Line 63: | Line 61: | ||
Body: | Body: | ||
- $.instance.deploy() | - $.instance.deploy() | ||
− | - $resources: new(io.murano.system.Resources) | + | - $resources: new('io.murano.system.Resources') |
− | |||
- $template: $resources.json('DeployTelnet.template') | - $template: $resources.json('DeployTelnet.template') | ||
- $.instance.agent.call($template, $resources) | - $.instance.agent.call($template, $resources) | ||
</syntaxhighlight> | </syntaxhighlight> | ||
− | === | + | Note, that: |
+ | * ''io.murano.system.Resources'' is a system class, defined in MuranoPL. | ||
+ | * ''io.murano.resources.Instance'' is a class, defined in the core Murano library, which is available here. This library contains Murano agent templates and init scripts. | ||
+ | |||
+ | ===Step 3. Prepare Dynamic UI Form Definition=== | ||
+ | Create a form definition in a yaml format. Before configuring a form, compose a list of parameters that will be required to set by a user. Some form fields that are responsible for choosing a flavor, image and availability zone are better to use in every application creation wizard. Syntax of Dynamic UI can be found [[Murano/Documentation/DynamicUI|here]]. | ||
+ | Full example with Telnet application form definitions is [[Murano/telnet_ui_definition|available here]]. | ||
+ | |||
+ | ===Step 4. Prepare application logo === | ||
+ | Find or create a simple image (in a .png format) associated with your application. Is should be small and have a square shape. You can specify any name of your image. In our example, let's name it ''telnet.png''. | ||
+ | |||
+ | ===Step 5. Prepare manifest file === | ||
+ | General application metadata should be described in the application manifest file. It should be in a yaml format and should have the following sections: | ||
+ | * '''Format''' - version of a manifest syntax format | ||
+ | * '''Type''' - package type. Valid choices are: ''Library'' and ''Application'' | ||
+ | * '''Name''' - human-readable application name | ||
+ | * '''Description''' - a brief description of an application | ||
+ | * '''Author''' - person or company name which created an application package | ||
+ | *'''Classes''' - MuranoPL class list, on which application deployment is based | ||
+ | *'''Tags''' - list of words, associated with this application. Will be helpful during the search. ''Optional'' parameter | ||
+ | |||
+ | ''Example'' | ||
+ | <syntaxhighlight lang="yaml"> | ||
+ | Format: 1.0 | ||
+ | Type: Application | ||
+ | FullName: io.murano.apps.linux.Telnet | ||
+ | Name: Telnet | ||
+ | Description: | | ||
+ | Telnet is the traditional protocol for making remote console connections over TCP. | ||
+ | Author: 'Mirantis, Inc' | ||
+ | Tags: [Linux, connection] | ||
+ | Classes: | ||
+ | io.murano.apps.linux.Telnet: telnet.yaml | ||
+ | UI: telnet.yaml | ||
+ | Logo: telnet.png | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | ===Step 6. Compose a zip archive === | ||
+ | An application archive should have the following structure: | ||
+ | * ''Classes'' folder | ||
+ | :MuranoPL class definitions should be put inside this folder | ||
+ | * ''Resources'' folder | ||
+ | :This folder should contain Execution scripts | ||
+ | :: Scripts folder | ||
+ | :: All script files, needed for an application deployment should be placed here | ||
+ | * ''UI'' folder | ||
+ | : Place dynamic ui yaml definitions here | ||
+ | * ''logo.png'' | ||
+ | : Image file should be placed in the root folder. It can have any name, just specify it in the manifest file. | ||
+ | * ''manifest.yaml'' | ||
+ | : Application manifest file. It's an application entry point. The file name is fixed. | ||
+ | |||
+ | Congratulations! Your application is ready to be uploaded to an Application Catalog. |
Latest revision as of 08:30, 21 April 2014
Contents
Composing application package manual
Murano is Application catalog that supports types of applications. This document intends to make composing application packages easily.
Step 1. Prepare Execution Plans
An Execution Plan is a set of metadata that describes the installation process of an application in a virtual machine. It's a minimal unit of execution that can be triggered in Murano Workflows and should be understandable by Murano agent. From Execution plans any script can be triggered. It could be any type of scripts which will execute commands and install application components as the result. Each script may consist of one or more files. Scripts may be reused across several Execution Plans. One of the scripts should be an entry point and should be specified in a resource template file in a Scripts. Besides this Scripts section the following section must be presented in a resource template file:
- FormatVersion - version of Execution Plan syntax format
- Version - version of Execution Plan
- Name - human-readable name of the Execution Plan
- Parameters - parameters received from MuranoPL
- Body - Python statement, should start with | symbol
- Scripts - dictionary that maps script names to script definitions.
- Scripts are the building blocks of Execution Plans and they may be executed as a whole (like a single piece of code), expose some functions that can be independently called in scripts. This depends on Deployment Platform and Executor capabilities. One script can be defined with the following properties:
- Type: Deployment Platform name that script is targeted to.
- Version: optional minimum version of deployment platform/executor required by the script.
- EntryPoint: relative path to the file that contains a script entry point
- Files: This is an optional array of additional files required for the script. Use <> to specify a relative path to the file. The root directory is Resource/scripts.
- Options: an optional argument of type contains additional options
Example DeployTelnet.template
FormatVersion: 2.0.0 Version: 1.0.0 Name: Deploy Telnet Parameters: appName: $appName Body: | return deploy(args.appName).stdout Scripts: deploy: Type: Application Version: 1.0.0 EntryPoint: deployTelnet.sh Files: - installer.sh - common.sh Options: captureStdout: true captureStderr: false
Step 2. Prepare MuranoPL class definitions
MuranoPL classes control application deployment workflow execution. Full information about MuranoPL classes can be found here.
Example
Namespaces:
=: io.murano.apps.linux
std: io.murano
res: io.murano.resources
Name: Telnet
Extends: std:Application
Properties:
name:
Contract: $.string().notNull()
instance:
Contract: $.class(res:Instance).notNull()
Workflow:
deploy:
Body:
- $.instance.deploy()
- $resources: new('io.murano.system.Resources')
- $template: $resources.json('DeployTelnet.template')
- $.instance.agent.call($template, $resources)
Note, that:
- io.murano.system.Resources is a system class, defined in MuranoPL.
- io.murano.resources.Instance is a class, defined in the core Murano library, which is available here. This library contains Murano agent templates and init scripts.
Step 3. Prepare Dynamic UI Form Definition
Create a form definition in a yaml format. Before configuring a form, compose a list of parameters that will be required to set by a user. Some form fields that are responsible for choosing a flavor, image and availability zone are better to use in every application creation wizard. Syntax of Dynamic UI can be found here. Full example with Telnet application form definitions is available here.
Step 4. Prepare application logo
Find or create a simple image (in a .png format) associated with your application. Is should be small and have a square shape. You can specify any name of your image. In our example, let's name it telnet.png.
Step 5. Prepare manifest file
General application metadata should be described in the application manifest file. It should be in a yaml format and should have the following sections:
- Format - version of a manifest syntax format
- Type - package type. Valid choices are: Library and Application
- Name - human-readable application name
- Description - a brief description of an application
- Author - person or company name which created an application package
- Classes - MuranoPL class list, on which application deployment is based
- Tags - list of words, associated with this application. Will be helpful during the search. Optional parameter
Example
Format: 1.0
Type: Application
FullName: io.murano.apps.linux.Telnet
Name: Telnet
Description: |
Telnet is the traditional protocol for making remote console connections over TCP.
Author: 'Mirantis, Inc'
Tags: [Linux, connection]
Classes:
io.murano.apps.linux.Telnet: telnet.yaml
UI: telnet.yaml
Logo: telnet.png
Step 6. Compose a zip archive
An application archive should have the following structure:
- Classes folder
- MuranoPL class definitions should be put inside this folder
- Resources folder
- This folder should contain Execution scripts
- Scripts folder
- All script files, needed for an application deployment should be placed here
- UI folder
- Place dynamic ui yaml definitions here
- logo.png
- Image file should be placed in the root folder. It can have any name, just specify it in the manifest file.
- manifest.yaml
- Application manifest file. It's an application entry point. The file name is fixed.
Congratulations! Your application is ready to be uploaded to an Application Catalog.