We could have been talking in my cube. My points when I'm discussing this with
coworkers generally go like so...
If you use this:
class { name: }
You will only be able to declare that name once. If you declare classes like
this:
include ::name
include ::name::otherclass
Then you will be able to include things anywhere you want without resource
conflicts.
You don't need to include a params class since you can inherit from it. Keep in
mind what the docs say about inheritance:
http://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html#inheritance
So for your stuff, some example subsets, pretending they're in different files:
class ntp::params {
$servers = ['reasonable', 'defaults']
$service_name = 'ntp'
$service_ensure = 'running'
$package_name = 'ntp'
$package_ensure = 'present'
}
class ntp::install (
$package_name = $ntp::params::package_name,
$package_ensure = $ntp::params::package_ensure,
) inherits ntp::params {
package { $package_name:
ensure => $package_ensure,
}
}
# (other classes here)
class ntp {
include ntp::install
include ntp::config
include ntp::service
Class['ntp::install'] -> Class['ntp::config']
Class['ntp::install'] ~> Class['ntp::service']
Class['ntp::config'] ~> Class['ntp::service']
}
Then you would control the install/config/service parameters via the hiera
automatic parameter lookup and avoid needing to explicitly hiera() or
hiera_hash(). (Hiera will do an auto-lookup anyway, though if you specify a
hiera() as the value of the class parameter, would it do the lookup twice? Not
sure, never tried it.)
If you don't know which kind of hiera lookup you may want, this module provides
a useful example of how to configure which one with hiera data:
http://forge.puppetlabs.com/mthibaut/users
On Mon, Mar 03, 2014 at 09:37:44AM -0800, Robin Bowes wrote:
> We're currently arguing^w discussing the use of the params class in
> conjunction with hiera lookups and we've arrived at what I think is a
> pretty good pattern. Let me explain by way of example, using the venerable
> ntp application
> class ntp{
> include ::ntp::params
> Class['::ntp::params']->
> class{'::ntp::install':}->
> class{'::ntp::config':}~>
> class{'::ntp::service':}->
> class{'::ntp::firewall':}->
> Class['::Ntp']
> }
> class ntp::params(
> $servers,
> $package_ensure = 'present',
> $service_ensure = 'running',
> $service_enable = true,
> ) {
> # os-specific stuff could go in here
> $packages = ['ntp']
> $service_name = 'ntpd'
> $config_file = '/etc/ntp/ntpd.conf'
> }
> class ntp::install{
> include ::ntp::params
> package{$::ntp::params::packages:
> ensure => $::ntp::params::package_ensure,
> }
> }
> class ntp::config{
> include ::ntp::params
> # explicitly declare any vars used in the template
> $servers = $::ntp::params::servers
> file{$::ntp::params::config_file":
> content => template(...)
> }
> }
> class ntp::service{
> include ::ntp::params
> service{$::ntp::params::service_name":
> ensure => $::ntp::params::service_ensure,
> enable => $::ntp::params::service_enable",
> }
> }
> class ntp::firewall{
> include ::ntp::params
> # firewall definition in here
> }
> The basic approach is that all user-changeable values are passed in via
> the params class. This class should be instantiated before the ntp class.
> Typically, this class would be used in a profile class something like
> this:
> class profile_ntp(
> $servers,
> ) {
> class{'::ntp::params':
> servers => $servers,
> }->
> class{'::ntp'}
> }
> Alternatively, $servers could come from an explicit hiera lookup:
> class profile_ntp{
> class{'::ntp::params':
> servers => hiera('ntp::servers')
> }->
> class{'::ntp'}
> }
> The hiera key would of course be profile_ntp::servers
> I can't decide whether I prefer the explicit lookup or the automatic
> approach.
> I'd be interested to hear any feedback on this approach.
> R.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
>
> [1]https://groups.google.com/d/msgid/puppet-users/8d0b5ce0-fb3c-4091-bd91-e4791a993616%40googlegroups.com.
> For more options, visit [2]https://groups.google.com/groups/opt_out.
>
> References
>
> Visible links
> 1.
> https://groups.google.com/d/msgid/puppet-users/8d0b5ce0-fb3c-4091-bd91-e4791a993616%40googlegroups.com
> 2. https://groups.google.com/groups/opt_out
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/20140303175501.GA10369%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/groups/opt_out.
