Execution plan template¶
An execution plan template is a set of metadata that describes the installation process of an application on a virtual machine. It is a minimal executable unit that can be triggered in Murano workflows and is understandable to the Murano agent, which is responsible for receiving, correctness verification and execution of the statements included in the template.
The execution plan template is able to trigger any type of script that executes commands and installs application components as the result. Each script included in the execution plan template may consist of a single file or a set of interrelated files. A single script can be reused across several execution plans.
This section is devoted to the structure and syntax of an execution plan template. For different configurations of templates, please refer to the Examples section.
The table below contains the list of the sections that can be included in the execution plan template with the description of their meaning and the default attributes which are used by the agent if any of the listed parameters is not specified.
Meaning and default value
a version of the execution plan template syntax
format. Default is
a human-readable name for the execution plan to be used for logging. Optional
a version of the execution plan itself, is used
for logging and tracing. Each time the content
of the template content changes (main script,
attached scripts, properties, etc.), the version
value should be incremented.
This is in contrast with
string that represents the Python statement and is executed by the murano-agent. Scripts defined in the Scripts section are invoked from here. Required
a dictionary of the
a dictionary that maps script names to their script definitions. Required
FormatVersion is a property that all other depend on.
That is why it is very important to specify it correctly.
FormatVersion 1.0.0 (default) is still used by Windows murano-agent.
Almost all the applications in murano-apps repository work with FormatVersion
2.0.0. New features that are introduced in Kilo, such as Chef or Puppet,
and downloadable files require version 2.1.0 or greater. Since FormatVersion
2.2.0 it is possible to enable Berkshelf. It requires Mitaka version of agent.
If you omit the
FormatVersion property or put something like
it will lead to the incorrect behaviour. The same happens if, for example,
FormatVersion=2.1.0, and a VM has the pre-Kilo agent.
Scripts are the building blocks of execution plan templates. As the name implies those are the scripts for different deployment platforms.
Each script may consists of one or more files. Those files are script’s program modules, resource files, configs, certificates etc.
Scripts may be executed as a whole (like a single piece of code), expose some functions that can be independently called in an execution plan script or both. This depends on deployment platform and executor capabilities.
Scripts are specified using
Scripts attribute of execution plan.
This attribute maps script name to a structure (document) that describes
the script. It has the following properties:
the name of a deployment platform the script is targeted to. The available alternative options for version>=2.1.0 are
Puppet, and for version<2.1.0 is
Applicationonly. String, required.
the minimum version of the deployment platform/executor required by the script. String, optional.
the name of the script file that is an entry point for this execution plan template. String, required.
the filenames of the additional files required for the script. Thus, if the script specified in the
EntryPointsection imports other scripts, they should be provided in this section.
The filenames may include slashes that the agent preserve on VM. If a filename is enclosed in the angle brackets (<…>) it will be base64-encoded. Otherwise, it will be treated as a plain-text that may affect line endings.
In Kilo, entries for this property may be not just strings but also dictionaries (for example,
filename: URL) to specify downloadable files or git repositories.
The default value is
that means that no extra files are used. Array, optional.
an optional dictionary of type
String->JsonObjectthat contains additional options for the script executor. If not provided, an empty dictionary is assumed.
Available alternatives are:
verifyExitcode(raise an exception if result is not positive). As Options are executor-dependent, these three alternatives are available for the Application executor, but may have no sense for other types.
verifyExitcoderequire boolean values, and have True as their default values.
Please make sure the files specified in EntryPoint and Files sections exist.