On Fri, Jan 7, 2011 at 2:47 AM, luke.bigum <luke.bi...@fasthosts.co.uk>wrote:
> Hi list,
>
> Reading the thread "can a class require an other class?" it's been
> mentioned that perhaps one way forward for the Puppet language is to
> phase out the include keyword in favour of parametrised classes. I'm
> thinking of my Puppet and the several levels of include chaining I use
> and I'm wondering how on earth that'd be possible. Maybe I'm designing
> my modules very differently to other people?
>
> I'll throw you an edited example from my environment and if the people
> who favour parametrised classes over includes could show me their
> alternatives that would be much appreciated. I haven't mentioned
> resources because the class names are pretty self explanatory - each
> class handles any package, service and config files related to it's
> name:
>
> node 'somenode' {
> include puppetmaster
> }
>
> class puppetmaster {
> include common
> include puppet
> include ldap_auth
> include iptables::disabled
> include httpd::ssl
> include ruby-enterprise::passenger
> }
>
> class ruby-enterprise::passenger {
> include common
> include httpd
> include ruby-enterprise
> }
>
> class httpd::ssl {
> include httpd
> }
>
The issue I'm trying to address is the current problem with scoping.
Considering class common, it will be nested inside of the puppetmaster OR
the ruby-enterprise::passenger class and it's not clear which one. Behavior
can change depending on which if variables or resource defaults are being
referenced outside the scope of class common.
My recommendation is to try and make sure common classes, like class
"common" are only included in one place that make sense for you. I would
personally write this collection of classes as:
(Note, this may be over-specifying dependency relationships, but ideally
this shouldn't be a huge problem for you if resources aren't establishing
direct relationships with resources in other classes. Run stages may also
be a good substitute for the require metaparameter on classes.)
Also, I'm totally open to suggestions to improve this organization scheme,
it clearly has issues but it's the best I've come up so far and works well
across the largest subset of Puppet deployments I've worked with.
node 'somenode' {
class { common: }
class { [ "ldap_auth",
"puppet",
"iptables::disabled",
"httpd",
"ruby-enterprise" ]: require => Class[common],
}
class { puppetmaster: require => Class[puppet] }
class { "httpd::ssl": require => Class[httpd] }
class { "ruby-enterprise::passenger":
require => Class["ruby-enterprise", "httpd"]
}
}
class puppetmaster { }
class ruby-enterprise::passenger { }
class httpd::ssl { }
Hope this helps,
--
Jeff McCune
http://www.puppetlabs.com/
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
