Jump to: navigation, search



THIS IS A DRAFT, feel free to read it to help finish drafting it, but it still needs some love.

The puppet-openstack module has traditionally served as a starting place. A place for new users to gravitate towards that they can initially use until it does not work for them. At that point, they can use it as an example of how to compose something custom.

This is problematic for the following reasons:

  • everyone rewrites the same top level logic. For the most part, this code is the same duplicated effort
  • no-one is testing quite the same code

The goal of this blueprint is to build something better that can be used universally and eventually be used to build products on top of.

why did puppet-openstack fail

In order to understand how to build something better, it makes sense to first explore why our predecessor failed.

  1. Data is directly forwarded through (at times multiple levels of) interfaces which leads to alot of duplicate error prone code.
  2. The explicit declarations of classes means that the classes are not composable (ie: ::all is not ::controller + ::compute)
  3. All parameters from each plugin are exposed through the same interface. This leads to class interfaces with too many parameters, and where only a subset of those parameters are used for any invocation. This means then when exploring a class interface, the end user has to not only grok all of the parameters, but also understand which ones apply to their use cases.


A single code base should should be able to support all of the following:

multiple deployment scenarios

There are an infinite number of possible deployment scenarios, and we should be able to support as many of them as possible.

The use cases initially being targeted with this new module is:

  • all in one
  • 2 node (controller/compute)
  • 3 node (controller/network/compute)
  • full active-active HA
  • multiple cinder backends (iscsi, ceph)
  • multiple quantum backends (ovs,provider networks)
  • multiple glance backend (file,swift,ceph)

support user specific configurations

Users need to be able to perform any adjustments to their openstack environment without having to submit a patch.

They should also be able to perform configuration based on hierarchical overrides.

be composable from common building blocks

The best explanation of this is that an all in one should be a controller + a compute roles.

specify implementation patterns that can be applied by future developers

become the community standard

should also meet the requirements of the community so that it becomes 'the way' to deploy openstack with Puppet

architectural components


Hiera is an external data lookup system that supports hierarchical data overrides.

It will be responsible for mapping class parameters of roles to their desired data values. Initially, this data will be stored in yaml files.

Hiera is a key to the solution b/c it allows data lookup to occur separately (and outside) of your puppet content. This means two things:

  • classes can be included in multiple locations (helps make higher level roles more composable)
  • classes do not have to forward their data to other classes.
  • These characteristics are key to supporting the ability to allow multiple deployment scenarios to be composed of shared building blocks.

puppet data bindings

Every class parameter in Puppet is automatically hooked up to hiera in Puppet 3.2 via Puppet's data bindings.

If you had a class:

  class foo($bar) {

you can override $bar by adding the key:


to your hiera data store.

This means that any data can be set externally from hiera, and that parameters never have to be passed.


Puppet has a built in introspection tool called resource_types.

This will be a key component of any future product that needs to export class parameters to the end ussr.

It is worth mentioning resources_types b/c all data will be passed as class parameters to ensure it is introspectable via this rest interface.


A typically modeling pattern that this module will be based on


Build out a new top level composition layer for the openstack modules.

Create wrapper for the components at the most fine grain level to ensure they can serve as the building blocks for a reasonable number of deployments.

The wrapper serves two purposes:

  1. maps multiple class parameters to the same value

Ensure the data for all of those components is resolved via hiera so that they can be combined without resulting in conflicts. This has the added benefit that the data can be more easily overrridden.