I see this with people looking to move to the hierarchical system that Hiera brings. It essentially boils down to "How do I do this without having a ton of hierarchy levels?". Usually we tend to recommend using the hierarchy to hit the 80% mark for the data you need in your modules. Anything that's module-specific-data should then be broken out to a data.pp or params.pp file with conditional logic there. I tend to ask people: "Is this something others are going to hit when they try to use the module too?", as in - "Are there path differences between operating systems?", or "Are there important changes to the data between RHEL 5 and 6?". If the answer to these is yes, then I tend to favor putting that data into a module's data class so that it's exposed for ANYONE who wants to use the module. Why would you want to hide these differences in the hierarchy - especially if others might run into them?
Does this sound similar to the problems you're facing? Or is this a case where you have custom facts that are specific to your organization that determine how you manage sysctl? On Fri, May 11, 2012 at 8:42 AM, Luke Bigum <luke.bi...@lmax.com> wrote: > Hi all, > > I've been improving our sysctl module and come across an interesting > design problem I'd like feedback on. > > I approached the re-factor with Hiera in mind - I would put all our sysctl > data in Hiera hash and pull that into a hiera_hash, merging the hierarchy > of data and allowing higher priority sysctl settings to override the > baseline defaults. I then use create_resources to write sysctl.conf. Works > great to start with, but now I come across more and more cases where the > sysctl data is dependent on machine logic (virtual vs physical, types of > hardware, etc) that doesn't seem right to put into Hiera as I'd have a > complex hierarchy for a bunch of edge case Facts. > > I seem to need to make decisions on two sources: business logic in Hiera > hierarchy (that's easy with merging hashes) as well as considering what > Facts or Classes applies to a node (machine logic). That's not trivial to > do, especially with a potentially large set of data like sysctl.conf keys. > > Does anyone have any thoughts or tips on how they might be managing a > similar situation? > > Thanks, > > -Luke > > -- > Luke Bigum > > Information Systems > Ph: +44 (0) 20 3192 2520 > luke.bi...@lmax.com | http://www.lmax.com > LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN > > > FX and CFDs are leveraged products that can result in losses exceeding > your deposit. They are not suitable for everyone so please ensure you > fully understand the risks involved. The information in this email is not > directed at residents of the United States of America or any other > jurisdiction where trading in CFDs and/or FX is restricted or prohibited > by local laws or regulations. > > The information in this email and any attachment is confidential and is > intended only for the named recipient(s). The email may not be disclosed > or used by any person other than the addressee, nor may it be copied in > any way. If you are not the intended recipient please notify the sender > immediately and delete any copies of this message. Any unauthorised > copying, disclosure or distribution of the material in this e-mail is > strictly forbidden. > > LMAX operates a multilateral trading facility. Authorised and regulated > by the Financial Services Authority (firm registration number 509778) and > is registered in England and Wales (number 06505809). Our registered > address is Yellow Building, 1A Nicholas Road, London, W11 > 4AN. > > -- > 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+unsubscribe@** > googlegroups.com <puppet-users%2bunsubscr...@googlegroups.com>. > For more options, visit this group at http://groups.google.com/** > group/puppet-users?hl=en<http://groups.google.com/group/puppet-users?hl=en> > . > > -- Gary Larizza Professional Services Engineer Puppet Labs -- 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.
