Skip to content
No description or website provided.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


Puppet Platform Manager

This is a simple prototype tool for building cross-host applications in Puppet and automatically choosing which hosts get which services.

It currently requires Dashboard.


This is very much a prototype and thought experiment. The idea is to see if we can specify cross-host applications, such as a three-tier web stack, in a single place, specify deployments of those applications, and then have those deployments automatically provision the needed classes on available hosts.

This prototype has cut a ton of corners - for instance, you can't have more than one Puppet class on a host. However, it does basically work. You specify the constituent classes in an application, and then you specify how many copies of each class you want in a deployment.

The classes themselves directly link to Puppet classes, and ppm knows how to look those classes up, extract their required parameters, etc.

It currently only integrates with Dashboard, and it directly uses the Dashboard libraries to read and write from the database (again, this is a prototype).

Provisioning of Puppet classes takes the form of finding Nodes in Dashboard that don't currently have any Puppet classes associated with them, and then assigning them one of the needed classes.

Example Setup

The basic setup is that you need some Puppet classes to do various things - see examples/lamp/modules/* for the classes used in our single example.

Once you have the Puppet classes, you need the new resource types defined in this repository -- profile (currently not used), constituent, application, and deployment. Here's a copy of the example at examples/lamp/applications/lamp.pp:

profile { large: ram => "4gb" }

constituent { rails: profile => large } constituent { mysql: profile => large } constituent { apache: profile => large }

application { lamp: constituents => [rails, mysql, apache] }

deployment { testing: application => lamp, password => 's3kr3t', rails => 3, mysql => 2, version => "3.0" }

They key bits here are the 'rails' and 'mysql' bits - we're specifying the number of instances of that class to deploy. The other parameters are needed by the various Puppet classes.

To run the example, start a Dashboard instance have Puppet and PPM in your $RUBYLIB, and run this:

./bin/ppm examples/lamp/applications/lamp.pp examples/lamp/modules/

This will fail, because you probably don't have any hosts in your dashboard. As you add hosts and rerun ppm, it will connect to the Dashboard database and automatically allocate each new host to one of the classes. Once it has allocated enough hosts, it will stop failing.

Things that don't work

ppm will fail if a deployment doesn't specify all of the parameters required by each of the needed classes, but it doesn't actually do anything else with those parameters. That is, there's no way to get those deployment parameters to the class instances. Thus, um, you can't actually use this to deploy any classes.

Even if it did work, it wouldn't work for parameters that are duplicated across classes - if both rails and apache have a 'version' parameter, you can't specify different values for each class. This is essentially a Puppet limitation.


This is very obviously a prototype, and it's unclear if this will be thrown away or turned into a real project. Thus, "future" is more about what we'd like to do rather than what will specifically be done in this project.

  • The class parameters specified in a deployment should be connected to the Puppet classes somehow
  • Some way of handling cross-class dependencies needs to be included -- e.g., if we don't want to start the rails service until mysql is up

And probably a lot more.

Something went wrong with that request. Please try again.