Murano is Application catalog that supports types of applications. This document intends to make composing application packages easily.
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 Scripts. Besides the Scripts section the following sections 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
MuranoPL classes control application deployment workflow execution. Full information about MuranoPL classes see here: MuranoPL: Murano Programming Language
Example telnet.yaml
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:
- $this.find(std:Environment).reporter.report($this, 'Creating VM for Telnet instace.')
- $.instance.deploy()
- $this.find(std:Environment).reporter.report($this, 'Instance is created. Setup Telnet service.')
- $resources: new('io.murano.system.Resources')
# Deploy Telnet
- $template: $resources.yaml('DeployTelnet.template')
- $.instance.agent.call($template, $resources)
- $this.find(std:Environment).reporter.report($this, 'Telnet service setup is done.')
Note, that
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 see at the corresponding section: Dynamic UI Definition specification. Full example with Telnet application form definition Telnet Definition.
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.
General application metadata should be described in the application manifest file. It should be in a yaml format and should have the following sections
Example manifest.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
Require:
io.murano.apps.TelnetHelper: 0.0.1
This step is optional. If you plan on providing images required by your application, you can include images.lst file with image specifications
Example images.lst
Images:
- Name: 'my_image.qcow2'
Hash: '64d7c1cd2b6f60c92c14662941cb7913'
Meta:
title: 'tef'
type: 'linux'
DiskFormat: qcow2
ContainerFormat: bare
- Name: 'my_other_image.qcow2'
Hash: '64d7c1cd2b6f60c92c14662941cb7913'
Meta:
title: 'tef'
type: 'linux'
DiskFormat: qcow2
ContainerFormat: bare
Url: 'http://path.to/images/file.qcow2'
If Url is omitted - the images would be searched for in the Murano Repository.
An application archive should have the following structure
MuranoPL class definitions should be put inside this folder
This folder should contain Execution scripts
All script files, needed for an application deployment should be placed here
Place dynamic ui yaml definitions here or skip to use the default name ui.yaml
Image file should be placed in the root folder. It can have any name, just specify it in the manifest file or skip to use default logo.png name
Application manifest file. It’s an application entry point. The file name is fixed.
List of required images. Optional file.
Congratulations! Your application is ready to be uploaded to an Application Catalog.