On Wednesday, March 11, 2015 at 1:57:00 PM UTC, Christopher Wood wrote:
>
>
> > Puppet in fact provides three functions functions for lookups: there
> is
> > also hiera_hash().
> >
> > In any case, you are quite right. Which sort of lookup is intended
> is an
> > attribute of the data -- part of the definition of each key -- but it
> is
> > not represented in or alongside the data. Each user of the data
> somehow
> > has to know. That could be tolerated, inconvenient as it is, except
> that
> > it is incompatible with automated data binding. This is an issue
> that has
> > been recognized and acknowledged, though I'm uncertain whether it is
> > actively being addressed.
>
> Could you possibly expound on the "Each user of the data somehow has to
> know" part? I'm having trouble with the notion that people would use puppet
> manifests and hiera data without knowing what's in them.
>
>
>
I can't speak for John but I think I get his meaning, but if I don't,
here's my own opinion ;-)
If a user of a module is reading that module's documentation and
parameters, it seems a bit nasty to assume they user must also go read the
Puppet module code in great detail to find out what type of Hiera call is
being used. Passing data to the module should be simply defined, eg: "this
parameter takes an array" or "this parameter is a comma separated string".
For a module to assume that it can or should attempt to do some sort of
deep merging seems overly complicated and it shifts the focus away from the
user providing the right data to a well written module. Rather than have
"classname::merge => true" I would advocate something like this which puts
the user in complete control of the data reaching it's modules in a correct
and easily testable manner:
class 'profile::dns' {
#lookup my DNS data
$hiera_dns_server_array = hiera_array('dns::server')
$common_dns_server = '127.0.0.1'
class { 'resolv':
dns_servers => [ $hiera_dns_server_array, $common_dns_server ]
}
Something like this seems like I'm telling a module *how* to look up my own
data, rather than passing the right data to the module:
class resolv (
$dns_servers_key_name = 'dns_servers',
$dns_servers_key_merge = false,
) {
if ($dns_servers_key_merge) {
$dns_servers = hiera_array($dns_servers_key_name)
} else {
$dns_servers = hiera($dns_servers_key_name)
}
}
class { 'resolv': dns_servers_key_merge => true }
I'd also have to code it to selectively use Hiera or not (some people
don't) and that would get even worse. The second example of module design
may be super awesomely flexible in terms of how I can structure my Hiera
data, but it doesn't fit the direction the community is moving in terms of
module design.
To answer Bostjan's original example, you have 3 "profiles" of syslog: one
base, one dc1 and one dc1_special, and you assign those profiles to
whatever node needs them.
-Luke
--
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/f3db0374-7555-402a-affd-3c162de2a4cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
