The evolution of modules' layouts

Over the years, different modules' layouts have been explored, following the evolution of Puppet's features and the refinement of usage patterns.

There has never been a unique way of writing a module, but patterns and best practices have emerged, and we are going to review the most relevant ones.

Class parameters – from zero to data bindings

The introduction of parameterized classes with Puppet 2.6 has been a crucial step in standardizing the interfaces of classes. In the earlier versions, there wasn't a unique way to pass data to a class, and variables defined anywhere could be dynamically used inside Puppet code or in templates to manage the module's behavior; there was no standard API to access or set them. We used to define parameterless classes in a similar fashion:

class apache {
  # Variables used in DSL or in templates were dynamically scoped 
  # and referenced without using their fully qualified name.
  # IE: $port, not $apache::port or $::apache_port...