On Sun, Mar 08, 2015 at 11:55:03AM -0700, Bostjan Skufca wrote: > Hi, > I am currently looking to move away from node inheritance towards hiera, > and I have a question how to achieve merge/overloading functionality with > hiera.
If I read these questions correctly, first look into the hiera functions: https://docs.puppetlabs.com/references/latest/function.html#hiera https://docs.puppetlabs.com/references/latest/function.html#hieraarray https://docs.puppetlabs.com/references/latest/function.html#hierahash > I have written an elaborate example below, but let me just quickly > summarize all that into a question: > With hiera: > - How would you go about when certain nodes need data merged from all > scopes, but other nodes need data from just the last scope? I've usually had a "classname::merge: true" key in hiera, controlling whether I use hiera() or hiera_hash() to obtain the data I need. > - What backend would you use? Using plain old yaml here, use whatever you feel like really. > - How would you best mimic the behaviour or node inheritance (regarding > array appends and replacements)? Conditionals in the puppet manifests to figure out whether I should use hiera() or hiera_array()/hiera_hash() (strbool in the example is from stdlib). class myclass ( $merge => false ) { if str2bool($merge) { $data = hiera_hash('myclass::data') } else { $data = hiera('myclass::data') } file { '/tmp/important.txt': content => template('myclass/imp.erb'), # $data used here } } In your position I might try doing hiera('myclass::data', fail()) to mimic a class parameter with no default, in case there was no sensible default and catalog compilation should fail without this data. If I recall correctly, a failed hiera*() lookup function just means a variable set to undef. That's if a default isn't fine, of course. As a last thing, have you possibly considered codifying your various include rules in a single template? Right now your "rules" on which syslog servers go where are all over the place (different hiera levels, puppet manifests) and it seems unnecessarily difficult to keep track of. If you can reduce your ruleset down to things like: machines in datacenter A get syslogs X, Y, Z machines of type B get syslogs F, G machines in datacenter A of type E get syslogs R, T Then you might find it easier to manage in code. Of course, maybe the disparate syslog infrastructure is a sign that things have become tangly and you need to prune syslog listeners a bit? Or, to rephrase, maybe spend the time correcting your syslog infrastructure rather than dealing with it in puppet? > - Probably I am looking towards custom backend, right? :) > Thank you for your opinions, > b. > Full example goes like this: > - there is a 'tpl_base' node template definition with all default > variables > - there is a 'tpl_base_dc1' node template which appends to inherited > values from 'tpl_base' > - there is a 'tpl_base_dc1_special' node template which REPLACES certain > values from 'tpl_base_dc1' > Let's implement this with node inheritance: > > ----------------------------------------------------------------------------------------- > node 'tpl_base' > { > #...(other vars)... > $syslog_servers = [ '9.9.9.51', '9.9.9.52' ] # Global syslog > servers > } > node 'tpl_base_dc1' > inherits 'tpl_base' > { > #...(other vars)... > $syslog_servers += [ '1.1.1.53', '1.1.1.54' ] # Additional syslog > servers for nodes in DC1 > } > node 'tpl_base_dc1_special' > inherits 'tpl_base_dc1' > { > #...(other vars)... > $syslog_servers = [ '1.1.1.55', '1.1.1.56' ] # REPLACE syslog > servers (note the = vs += operator) > } > node 'srv-0.no-dc' > inherits 'tpl_base' > { > include 'syslog_ng' > } > node 'srv-1.dc1' > inherits 'tpl_base_dc1' > { > include 'syslog_ng' > } > node 'srv-2-special.dc1' > inherits 'tpl_base_dc1_special' > { > include 'syslog_ng' > } > > ----------------------------------------------------------------------------------------- > The result is: > - nodes from all datacenters log to 9.9.9.51 and 9.9.9.52 syslog servers > - nodes from dc1 additionaly log to dc1-specific logservers, 1.1.1.53 and > 1.1.1.54 > - SPECIAL nodes from dc1 log do specially designated log servers (.55 and > .56) and not to other log servers (consider they are logging > security-sensitive data which must not be visible on common log servers > - this aligns neatly with module/class definitions, as they do not have to > care about how data arrays are costructed (defined, appended, replaced, > whatever), they just use whatever is given to them > Now lets remodel this into hiera scopes: > > ----------------------------------------------------------------------------------------- > # /etc/hiera.yaml > --- :hierarchy: > - "%{::clientcert}" > - "tpl_%{::domain}" <-- one way to include dcX-specific configuration > - "tpl_base" > # tpl_base.yaml > syslog_servers: > - 9.9.9.51 > - 9.9.9.52 > # tpl_dc1.yaml > syslog_servers: > - 1.1.1.53 > - 1.1.1.54 > # tpl_dc1-special.yaml > syslog_servers: > - 1.1.1.55 > - 1.1.1.56 > > ----------------------------------------------------------------------------------------- > When data is ported into hiera, there are two options available for > retrieving data: > a) hiera() > b) hiera_merge() > These would be the results: > 1. hiera() would work fine for srv-0.no-dc (just global syslog servers) > 2. hiera() would work fine for srv-2-special (just specific servers for > special nodes) > 3. hiera_merge() would work fine for srv-0 > 4. hiera_merge() would work fine for srv-1 (merges base and dc1-specific > syslog servers) > 5. hiera() would NOT work fine for srv-1 (gets just dc1-specific syslog > servers, as it is the most specific match) > 5. hiera_merge() would NOT work fine for srv-2 (gets ALL syslog servers, > despite only last two being a reqirement) > Problematic are last two cases, which (as it seems) are not supported with > current hiera backends. Or am I wrong? > 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 [1]puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > > [2]https://groups.google.com/d/msgid/puppet-users/7205e414-506f-41b4-8c5d-c1e0a9da1d4e%40googlegroups.com. > For more options, visit [3]https://groups.google.com/d/optout. > > References > > Visible links > 1. mailto:puppet-users+unsubscr...@googlegroups.com > 2. > https://groups.google.com/d/msgid/puppet-users/7205e414-506f-41b4-8c5d-c1e0a9da1d4e%40googlegroups.com?utm_medium=email&utm_source=footer > 3. 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20150308215522.GA10799%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
