(inline)
On Mon, Mar 03, 2014 at 06:24:47PM +0000, Robin Bowes wrote:
> Hi Christopher,
> On 3 Mar 2014, at 17:55, Christopher Wood <[1]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:
>
>
> [2]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.
How did it bite you? Somebody around here tried using module::params::variable
in hiera and found it didn't work for them. They had to use the
module::class::variable even though it had a params default.
> 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.
The confusion seems to depend on if you value whether or not the content of the
string has any meaning beyond whether it's sourced correctly from puppet/hiera.
I am likely explaining this badly, but at this level the fact that the string
matches puppet/hiera is sufficient. The content only matters at the level using
the value for something, and arbitrary strings of metadata is a good way to run
into trouble. Better to enforce that people use something already there for
this purpose ($title) which is a cultural problem not a technological one.
To wit, with different results for the commenting/uncommenting (bad use of
class not include for the hiera-less example):
class params {
$bar = "not params class"
notice($title)
}
class other (
$bar = $params::bar,
) inherits ::params {
notice($bar)
notice($title)
}
class { 'other':
#bar => 'useless string rhubarbing',
}
This provides my expected result, since I'm using the $title variable rather
than a string I've set myself.
As to that blog post, my mileage definitely varied. The pattern choice seems to
depend more on what any group of sysadmins prefers than any specific point of
utility.
> 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] [3]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
>
> [4]https://groups.google.com/d/msgid/puppet-users/C3FDC7C0-B150-4D1B-B075-D97F7D7B66D0%40yo61.com.
> For more options, visit [5]https://groups.google.com/groups/opt_out.
>
> References
>
> Visible links
> 1. mailto:christopher_w...@pobox.com
> 2.
> http://docs.puppetlabs.com/puppet/latest/reference/lang_classes.html#inheritance
> 3. http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/
> 4.
> https://groups.google.com/d/msgid/puppet-users/C3FDC7C0-B150-4D1B-B075-D97F7D7B66D0%40yo61.com
> 5. 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/20140303192514.GA10803%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/groups/opt_out.
