On Apr 7, 9:18 am, Jeff <jixe...@hotmail.com> wrote: > Hi puppeteers, > > I’m starting from scratch with Puppet 2.7 and I’m trying to avoid some > pitfalls from the past using another configuration management tool. I > think most of the issues I had could be solved by Puppet and Hiera but > being new to the tool and the approach, Im seeking for advice. > > I have a common use case with the configuration of sysctl settings I > believe will help me understand if Hiera is the right tool or approach to > the problem. Now the requirements are : > > 1) All nodes get a set of default settings > > 2) Based on facts such as function/application, settings are added > incrementally > > 3) A default setting might be overridden for a specific use. > > The ‘old’ way I used to solve this was through templating and lots if/else > statements… but that’s exactly what Im trying to avoid as the knowledge > about the infrastructure gets spread everywhere.
Note that with Puppet, templates are processed on the *master* (based on node facts), so templates do not leak knowledge. Nodes see only their copy of the resulting file. That does not make the template solution elegant, but it might be useful information for you to have. > When I found about the Puppet and Augeas combination I thought that was > the solution. I also wanted an ENC and using hiera sound great also. > [...] Now the issue is that only the settings found in role-ap.yaml are > applied. > It looks like hiera stops at the first array matching in the hierarchy. Did > I got this all wrong? The hiera() function performs a priority lookup, stopping at the first match for the requested key. This is what allows you to override values defined at low-priority levels of your data hierarchy with values defined at higher levels. If you want instead to collect all the values for a key defined at any level of your hierarchy, then use the hiera_array() or hiera_hash() function instead. There is an example toward the end of http://puppetlabs.com/blog/first-look-at-installing-and-using-hiera/ > The other issue with this approach is I can’t define a ‘’sysctl_${name}’ > resource twice so overriding a parameter doesn’t work either. How can I > get the same result as with capitalization of a File resource for example? Puppet uses capitalization of resource type names for a few different purposes. All of those revolve around referring to resource instances declared elsewhere, but I'm not sure which you have in mind. If you're trying to override resource properties then that is better achieved via Hiera (see my comments above about priority lookup), especially given that you're using Hiera already. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.