Pluggable Package Types

URL of launchpad blueprint:

This spec is about making possible to support different package formats (besides MuranoPL/1.x and Heat.HOT/1.0) via package format plugins.

Problem description

There are many different formats that can be used to describe applications besides MuranoPL. Currently Murano supports 2 package types MuranoPL/1.x and Heat.HOT/1.0. However because they both are parts of Murano source codes it is impossible to add additional types without merging them into main source tree thus making Murano team responsible for all of them.

Proposed change

It is proposed to have support for non-MuranoPL packages the same way HOT support is implemented: by dynamic generation of MuranoPL code at run time. However the package types themselves need to be pluggable so that anyone could extend Murano with additional package type by installing corresponding plugin.

It is proposed to use stevedore library and similar approach to how MuranoPL python plugins are currently handled.

Package types plugins will be identified by dedicated namespace io.murano.plugins.packages. To specify package type one should append to plugin’s setup.cfg file

io.murano.plugins.packages =

For example:

io.murano.plugins.packages =
    Cloudify.TOSCA/1.0 = murano_cloudify_plugin.cloudify_tosca_package:CloudifyToscaPackage

If target package type requires some utility to construct it (e.g. put right files in right folders, zip them, generate manifest and so on) than it should also be included in the plugin as additional shell endpoint.



Data model impact


REST API impact


Versioning impact

None. There cannot be 2 versions of the same plugin simultaneously. However single plugin may support several different package formats including severals different versions of the same format using single of several Python classes. Version number remains part of format string.

Other end user impact


Deployer impact

Plugins need to be deployed to each Murano node (or to all machines running either Murano API or Murano Engine) in order to support particular package type. Installation is done as usually in python (pip install PATH or python install etc.)

Developer impact


Murano-dashboard / Horizon impact




Primary assignee:
Stan Lagun <>

Work Items

  1. Refactor current package class hierarchy, change order of __init__ parameters so that format name and version will become the first two. This is required because they will be supplied automatically by plugin loader.
  2. Implement plugin loader that would find all installed stevedore plugins in io.murano.plugins.packages and build internal mapping format name/version -> Python implementation class
  3. Add function to register in that mapping implementations that remain inside Murano sources like MuranoPL package type
  4. Add method to retrieve Package instance of supplied format name/version. Plugin-loader should return class factory that will instantiate appropriate Python class for particular format by substituting first 2 arguments (format name and version) while the rest arguments will be supplied by the caller.
  5. Refactor load_utils to use plugin-loader rather than its own hardcoded mapping.


stevedore library


Testing can be performed by attempt to deploy application that is not in native Murano format like TOSCA is.

Documentation Impact

Guide that tells how to develop custom package type plugins need to be published.