Jump to: navigation, search

Difference between revisions of "Murano/Documentation/How to create application package"

(Step3. Prepare Dynamic UI Form Definition)
(Step4. Prepare manifest file)
Line 72: Line 72:
  
 
===Step4.  Prepare manifest file ===
 
===Step4.  Prepare manifest file ===
General metadata should be described in manifest file. It should be in yalm format and should has the following sections:
+
General metadata should be described in manifest file. It should be in yaml format and should has the following sections:
* '''Format''' - vervion of manifest syntax format
+
* '''Format''' - version of manifest syntax format
 
* '''Type''' - package type. Valid choices are: ''Library'' and ''Application''
 
* '''Type''' - package type. Valid choices are: ''Library'' and ''Application''
 
* '''Name''' - human-readable application name
 
* '''Name''' - human-readable application name
* '''Description''' - a brief description of application
+
* '''Description''' - a brief description of an application
* '''Author''' - person or company name witch created a application package
+
* '''Author''' - person or company name which created an application package
*'''Classes''' - MuranoPl class list, on which application deployment is based
+
*'''Classes''' - MuranoPL class list, on which application deployment is based
*'''Tags''' - list of words, assotioated with this applciation. Will be helpful during search. ''Optional'' parameter
+
*'''Tags''' - list of words, associated with this application. Will be helpful during search. ''Optional'' parameter
  
 
Example:
 
Example:

Revision as of 08:21, 15 April 2014

Composing application package manual

Murano is Application catalog that supports types of applications. This document intends to make composing application packages easily.

Step1. 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 Execution Plan script or both. 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

Step2. 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)

Step3. 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 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 avaliable here.

Step4. Prepare manifest file

General metadata should be described in manifest file. It should be in yaml format and should has the following sections:

  • Format - version of 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 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