Hi Christopher,
On 3 Mar 2014, at 17:55, Christopher Wood <christopher_w...@pobox.com> wrote:
> 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.
Yes, I realise that. Hence the suggestion to use a profile_ntp class that may
be included multiple times 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']
> }
This is essentially how we've been using the params class until very recently.
One of the concerns raised by the use of inheritance was the duplication
involved in declaring everything in two places, ie. in the params class and the
class that inherits the params class (the ntp::install class in your example).
Additionally, it creates two places in which the parameters can be
automatically set. eg. ntp::install::package_name and ntp::params::package_name
- this has bitten us a couple of times.
Note also that it is not necessary to pass all params to the inheriting class.
Take this example:
class foo::params{
$bar = 'params class'
}
class foo inherits ::foo::params {
notify{$bar:}
}
$bar will contain 'params class' as it is inherited from foo::params.
Potentially confusing.
This pattern is also influence by one of Gary Larizza's blog posts [1] in which
he recommends:
"
Do all Hiera lookups in the profile
"
Having worked with roles/profiles/modules for some time, and having ended up
with a confusing mess of hiera data, some automatically included, some not,
that statement was a lightbulb-moment for me. My aim now is to write my modules
to pass in all required information via parameters and to do the lookups at the
profile level, either explicitly with hiera() lookups or automatically with APL.
As always, there are many ways to skin this particular cat, and YMMV. :)
R.
[1] http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/
--
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/C3FDC7C0-B150-4D1B-B075-D97F7D7B66D0%40yo61.com.
For more options, visit https://groups.google.com/groups/opt_out.
