On Wednesday, 11 March 2015 15:59:12 UTC+1, Luke Bigum wrote:
>
>
> On Wednesday, March 11, 2015 at 1:57:00 PM UTC, Christopher Wood wrote:
>>
>>
>> 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.
>
Spot on, I believe.
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.
>
This is almost what I am looking for. I have an alternate approach: what if
merging vs nonmerging is decided based on hiera key?
class resolv (
$dns_servers_key_name = 'dns_servers',
) {
if (hiera('dns_servers_key_merge')) { # <--- hiera is
responsible for merging decision
$dns_servers = hiera_array($dns_servers_key_name)
} else {
$dns_servers = hiera($dns_servers_key_name)
}
}
Though I can forsee the problem in this case:
- layer 1 data, merge value has no effect here
- layer 2 data, merge true <--- correct, data from layer 1 and layer 2
is merged
- layer 3 data, merge false <--- if we stop here, only data from layer 3
is used
- layer 4 data, merge true <--- this would cause merging of data from
all layers
b.
--
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/d2bd3ad8-d807-4543-823b-985bb0ce8179%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
