Up until this point, classes and defines were presented as direct opposites with respect to flexibility; defined types are inherently adaptable through different parameter values, whereas classes model just one static piece of state. As the section title suggests, this is not entirely true. Classes too can have parameters. Their definition and declaration become rather similar to those of defined types in this case:
class apache::config(Integer $max_clients=100) {
file { '/etc/apache2/conf.d/max_clients.conf':
content => "MaxClients ${max_clients}
",
}
}With a definition like the preceding one, the class can be declared with a parameter value:
class { 'apache::config':
max_clients => 120,
} This enables some very elegant designs, but introduces some drawbacks as well.
The consequence of allowing class parameters is almost obvious: you lose the singleton characteristic. Well, that's not entirely true either, but your freedom in declaring the class gets limited drastically.
Classes that define default values for all parameters can still be declared with the include statement. This can still be done an arbitrary number of times in the same manifest.
However, the resource-like declaration of class { 'name': } cannot appear more than once for any given class in the same manifest. This is in keeping with the rules for resources and should not be very surprising—after all, it would be very awkward to try and bind different values to a class's parameters in different locations throughout the manifest.
Things become very confusing when mixing include with the alternative syntax though. It is valid to include a class an arbitrary number of times after it has been declared using the resource-like notation. However, you cannot use the resource style declaration after a class has been declared using include. That's because the parameters are then determined to assume their default values, and a class { 'name': } declaration clashes with that.
In a nutshell, the following code works:
class { 'apache::config': }
include apache::configHowever, the following code does not work:
include apache::config
class { 'apache::config': }As a consequence, you effectively cannot add parameters to component classes, because the include statement is no longer safe to use in large quantities. Therefore, parameters are essentially only useful for comprehensive classes, which usually don't get included from different parts of the manifest.
Note
In Chapter 5, Extending Your Puppet Infrastructure with Modules, we will discuss some alternate patterns, some of which exploit class parameters. Also note that Chapter 8, Separating Data from Code Using Hiera, presents a solution that gives you more flexibility with parameterized classes. Using this, you can be more liberal with your class interfaces.
Ever since class parameters have been available, some Puppet users have felt compelled to write (example) code that would make it a point to forgo the include keyword in favor of resource-like class declarations, such as this:
class apache {
class { 'apache::service': }
class { 'apache::package': }
class { 'apache::config': }
}Doing this is a very bad idea. We cannot stress this enough: one of the most powerful concepts about Puppet's classes is their singleton aspect—the ability to include a class in a manifest arbitrarily and without worrying about clashes with other code. The mentioned declaration syntax deprives you of this power, even when the classes in question don't support parameters.
The safest route is to use include whenever possible, and to avoid the alternate syntax whenever you can. In fact, Chapter 8, Separating Data from Code Using Hiera, introduces the ability to use class parameters without the resource-like class declaration. This way, you can rely solely on include, even when parameters are in play. These are the safest recommended practices to keep you out of trouble from incompatible class declarations.