I suspect duplicate keys are not valid YAML. R. On 1 Apr 2014 17:51, "Matthew Burgess" <[email protected]> wrote:
> 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<https://groups.google.com/d/msgid/puppet-users/CAKUTv3JLCw_FWJTnf8ZCJ_RtWuLKvwG6afa5oECxB1R%3DxKdjHQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > 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/CAJGKfwDhE7t-0qK9TpDHrZ6j_ePM6_%2BwK-K%2BUFfBRw0C3qJdow%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
