On 2 May 2014 23:04, Andreas Ntaflos <d...@pseudoterminal.org> 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? 2) Is there a reason why the automatic class parameter binding uses hiera() and not hiera_hash() when the parameter is a hash? 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. Thanks, Matt. -- 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/CAKUTv3JMSmmkKEvvcsWF-wffRYM0BEHG3vopbgHdAiNS7F8vhw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
