Apologies for that last email; hiera_hash() is obviously doing *nearly* the right thing, as it *does* merge hashes across different levels of the hierarchy. It *doesn't* seem to be merging hashes within the same level of the hierarchy.
Thanks, Matt. On 1 April 2014 17:35, Matthew Burgess <[email protected]> wrote: > Thanks Felix. > > I'm using the system module (https://forge.puppetlabs.com/erwbgy/system) > and the system::packages module *is* using hiera_hash() ( > https://github.com/erwbgy/puppet-system/blob/master/manifests/packages.pp) > (as is system::services which is also causing me the same problem). > > I assume hiera_hash()'s behaviour is default, i.e. I don't need to set > :merge_behaviour in hiera.yaml? > > In addition, running 'hiera' to debug this shows the same behaviour; I > assume there isn't a native hiera equivalent to Puppet's hiera_hash() > function? > > Cheers, > > Matt. > > > On 1 April 2014 17:17, Felix Frank <[email protected]>wrote: > >> Hi, >> >> long story short: This is what the hiera_hash() function is for (as >> opposed to hiera()). >> >> HTH, >> Felix >> >> On 04/01/2014 06:15 PM, Matthew Burgess wrote: >> > Hi folks, >> > >> > In my common.yaml file I have the following hiera hashes: >> > >> > system::packages: >> > sshd: >> > ensure: 'present' >> > ... >> > ... >> > more stuff here >> > ... >> > system::packages: >> > ntpd: >> > ensure: 'present' >> > >> > I naively assumed that Hiera would merge those 2 hashes together, just >> > as it does if they were present in different layers of the hierarchy. >> > It appears, though, that the latter simply overrides the former; I have >> > an sshd service with a dependency on the sshd package, but with the >> > above hiera data, the catalog fails to compile as the sshd package isn't >> > in the catalog. >> > >> > Am I just missing some YAML syntax to stop the hash from being >> > overwritten, or am I perhaps misunderstanding the behaviour I'm seeing >> > here? I did test manually merging the hashes in the YAML file and that >> > did indeed 'fix' the problem. >> > >> > If that behaviour is simply a fact of life, that's fine too; I'll fix >> > the data up, although there was an aesthetic/organisational reason for >> > having it structured as it is currently. >> > >> > 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-users/533AE688.3070702%40alumni.tu-berlin.de >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAKUTv3JLCw_FWJTnf8ZCJ_RtWuLKvwG6afa5oECxB1R%3DxKdjHQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
