(also inline)
On 3 Mar 2014, at 19:25, Christopher Wood <christopher_w...@pobox.com> wrote:
> (inline)
>
> On Mon, Mar 03, 2014 at 06:24:47PM +0000, Robin Bowes wrote:
>>
>> 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.
It worked just fine, but it meant that there were two places where a value
could be set, $foo::params::bar and $foo::bar. Given a non-trivial hiera config
(ie. more than a couple of levels, spread across multiple modules), it is easy
to end up using both and not understand when changing one of them does not work
(because it is over-ridden by the other one of which you are not aware).
>
>> 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.
No, I mean that variables from the foo::params class "pollute" the main foo
class, even without being explicitly imported or declared. I find this opaque
and non-intuitive. I find this much clearer:
class foo::params{
$bar = 'some value'
}
class foo{
include ::foo::params
$bar = $::foo::params::bar
}
> 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.
I'm not sure what this example is trying to show?
> 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.
Oh, absolutely - there are lots of ways to do things and the final choice
depends on many factors, and it's not always the most technically pure (in a CS
way) that wins out.
I still think it makes a lot of sense to not do hiera lookups from "base"
modules and instead group them all in the profile modules so all data lookups
are done in one place. It's certainly a lot clearer.
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
https://groups.google.com/d/msgid/puppet-users/7A7631C9-78EF-4788-A38F-36BF85C3B877%40yo61.com.
For more options, visit https://groups.google.com/groups/opt_out.
