On Friday, May 2, 2014 5:40:24 PM UTC-5, Matthew Burgess wrote:
>
> On 2 May 2014 23:04, Andreas Ntaflos <da...@pseudoterminal.org<javascript:>
> > wrote:
>
>> Sound like you want to install deep-merge (packaged by Puppetlabs for
>> Debian as "ruby-deep-merge" and for RedHat as "rubygem-deep-merge") on
>> the Puppet master, set ":merge_behavior: deeper" in
>> /etc/puppet/hiera.yaml (and/or /etc/hiera.yaml) and restart the Puppet
>> master.
>>
>
> Hmm, I already have that configuration setup (Hiera 1.2.1 with deepmerge
> installed and 'deeper' specified in hiera.yaml). Other Hiera hashes are
> getting merged correctly, although they never try to override an element of
> the hash, they simply define additional elements of the hash. Indeed that
> works with the example above; if I specify something like an 'app_vol' LV,
> which doesn't exist in the common.yaml has, the server ends up with all of
> the common.yaml entries + the extra app_vol. This failing case is where I
> have the var_vol LV defined in *both* levels of the hierarchy, at which
> point Hiera decides to replace the entire hash with the highest priority
> version of the hash instead of recursively merging the values defined
> therein.
>
> Just googling a bit leads me to a really small nuance in the text in the
> link you posted. The merge behaviour described on that page is for 'hash
> merge lookups' and not every Hiera lookup is that. In particular,
> automated class parameter binding uses hiera() not hiera_hash() so doesn't
> do a hash merge lookup. If I've read the code in lvm/init.pp correctly,
> that appears to be the reason for what I'm seeing.
>
> So, I guess there's 3 questions now:
>
> 1) Have I understood the code and documentation correctly and come to the
> correct conclusion about why I'm seeing the behaviour I am?
>
Yes, class parameter binding proceeds via hiera() in all cases. Hash merge
behavior is obtained only by explicitly calling hiera_hash().
> 2) Is there a reason why the automatic class parameter binding uses
> hiera() and not hiera_hash() when the parameter is a hash?
>
Puppet doesn't know the value's type until it looks it up. Furthermore, it
does not follow from the value being a hash that hash-merge is the desired
lookup flavor. Generally, that doesn't even follow from details of the
class in question -- it is strictly a data definition matter.
>
> 3) Is there anything I can do to 'fix' this particular issue? I don't mind
> carrying a local patch to puppetlabs/lvm if that's what's required, or a
> config change. If not, I'll just have to resign myself to having data
> duplication; the number of places we have to override the size of a common
> filesystem is very low, as are the chances that the common filesystem sizes
> will change in common.yaml.
>
>
I think you could achieve this without modifying your data by turning on
'deeper' merging and patching class lvm in lvm/manifests/init.pp like so:
class lvm {
$volume_groups = hiera_hash('lvm::volume_groups', {})
validate_hash($volume_groups)
create_resources('lvm::volume_group', $volume_groups)
}
Note that that ties you to drawing the volume group information from Hiera
(whereas otherwise you could, in principle, specify it in DSL at the point
where you declare class lvm). That's in fact what you are doing, however,
and indeed what you *should* be doing.
John
--
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/ac788c7f-cfc8-4b72-bac6-70ed7000165b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
