On Friday, December 7, 2012 1:45:23 PM UTC-6, Wolf Noble wrote:
>
> Hi Gary,
>
>
> I know what you mean, and agree for modules destined to be released to the
> wild.
> unfortunately, we have a diverse enough environment that even the defaults
> occasionally need to be overridden; hence the hierification.
> (I've got all that logic wrapped into a case statement based on if the
> global parameter hiera_enabled is true or false, with sane-ish defaults
> when hiera isn't enabled)
>
You're not talking about the same thing, then. The non-site specific
defaults Gary is talking about would be (in this case) the package names
used by the OS distribution. I'm inclined to agree with him that it makes
the most sense to associate those tightly with the module, whether by
encoding them somehow in your manifests or by putting them in an Hiera data
file that is bound to the module and distributed with it (as R.I. has been
demonstrating).
For site-specific details stored in hiera, you really have only two basic
alternatives:
1. distinguish data by the files in which they are recorded, or
2. distinguish data by the keys with which they are associated
In fact, you always use some combination of both, so your question boils
down to choosing the best mix. Unfortunately, we can't really answer that
for you. It's too dependent on the priorities, practices, and preferences
of your organization and its people.
Myself, I prefer to minimize conditionals in my manifests where I can by
relying on data instead. Thus, for example, I might consider a variation
on your engineer's suggestion such as this:
class foobar::params {
$default_package = {
'RedHat' => 'foobar',
'Debian' => 'foobard'
}
$package = hiera("foobar_os_${::osfamily}_package",
$default_package[$::osfamily])
}
The approach R.I. is testing amounts to doing more or less the same thing,
but using an hiera data file belonging to the module instead of
$foobar::params::default_package, which has the great advantage that your
manifests don't need to change when you add support for a new OS family.
The approach R.I. first suggested differs from that mainly in the location
of the additional data file and its position in the hierarchy (first
instead of last).
Alternatively, you could go meta with it, along the lines of this model:
class foobar::params {
$package_key = hiera('foo_package_key')
$package = hiera($package_key)
}
That abandons the idea of non-site-specific data being tightly bound to the
module, but the extra layer of indirection through Hiera gives you a great
deal of additional flexibility. If that appeals to you then I'm sure you
can see several directions to run with it.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/yb_CNvnn7G0J.
To post to this group, send email to puppet-users@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.
