Configuration Language Support

Problem description

There is a huge community of applications (opscode, puppet-labs) where deployment installation instructions are specified in configuration languages such as Puppet or Chef. In order to reuse these applications, adaptors like Chef or Puppet are required on the VM side. Both chef and puppet recipes will not be managed by centralized server (chef-server, puppet-master), but they will use the standalone version, specifically the usage of chef-solo and puppet apply.

Proposed change

Inclusion of new executors in the murano-agent project. These executors will be objects to be used by murano-agent. Specifically, two executors will be implemented: Puppet and Chef. Both executors will be in charge of:

  • Obtaining the required modules or cookbooks in the virtual machine.

This task can be done by passing the information from murano-engine to murano-agent, obtaining the information from the package itself. It requires the user to upload the package information plus the cookbooks to be used. The second option implies the cookbooks are downloaded in the virtual machine, so that they only need the URL to be accessible.

  • Generating the required files for the configuration language.

For instance, manifests and hiera data for puppet, and, node specifications for chef from the information stored in the execution plan.

  • Executing the chef-solo or puppet-apply process.

Previously, some work has to be done to install Chef or Puppet inside the VM. This task can be done by using cloud-init from the murano engine. The following is an example on how these executors work:

## YAML Template.
FormatVersion: 2.0.0
Version: 1.0.0
Name: Deploy Tomcat
    port: $port
Body: |
    return deployTomcat(port=args.port).stdout
        Type: Chef
        Version: 1.0.0
        EntryPoint: mycoockbook::myrecipe
                Name: tomcat
                URL: git://
                Type: Downloadable
                Name: java
                URL: git://
                Type: Downloadable
                Name: openssl
                Type: Downloadable
    captureStdout: true
    captureStderr: true

In this case, a new script Type appears (instead of Application). It is Chef type, which will execute the Chef executor. The same happens with the Puppet Type. In addition, the EntryPoint contains the information about the cookbook and the recipe to be installed. The Files section is used for the cookbooks and its dependence information. The cookbooks properties are in the Parameter section.

All the required steps to be part of the executor can be summarized as follows.

For Chef,

  1. Creating the node.json with the recipes and the configuration parameters:

        orion::ports: 1026
        orion::dbname: oriondb
        "run_list": [
  2. Executing chef-solo:

    chef-solo -j node.json

For puppet,

  1. Generating the manifest (site.pp):

    node 'default'
  2. Creating the hiera data information: hiera.yaml:

    ## YAML Template.
    orion::port: 1026
    orion::dbname: oriondb
  3. Executing:

    puppet apply –hiera_config=hiera.yaml –modulepath=/opt/puppet/modules/orion site.pp



Data model impact


REST API impact


Versioning impact


Other end user impact


Deployer impact

The solution proposed is valid for any VM which contains the configuration language implementation already installed. There are event chef-solo and puppet agents for Windows.

Developer impact


Murano-dashboard / Horizon impact




Primary assignee:
Other contributors:

Work Items

  1. Generate Chef executor
  2. Generate Puppet executor
  3. Work on configuration




Integration tests will be done

Documentation Impact

Information about how to defines application for Puppet and Chef will have to be documented, explaining the different fields.