I suppose you could create a separate class for the entries that will
be fact-driven versus Hiera-driven. You wouldn't be able to use a
single template, but either augeas or concat should work. I wouldn't
call it elegant, but the code might be less ugly.
On Fri, May 11, 2012 at 9:47 AM, Luke Bigum <luke.bi...@lmax.com> wrote:
> Hi Gary,
>
> Not quite... Let me go into more detail.
>
> I'm trying to handle sysctl "perfectly" which is probably my real problem.
> Hiera's ability to merge hashes together makes it perfect for arriving at
> one set of sysctl options for a server based on "business logic" (my
> hierarchy). For Hiera data on 'someserver' below which has 'some_role',
> calling hiera_hash in a Puppet manifest will give me IP forwarding set and
> rp_filter set, which is what I want:
>
> --------- some_role.json ------------
> {
> "sysctl" : {
> "net.ipv4.ip_forward" : {
> "comment" : "Controls IP packet forwarding",
> "value" : "1"
> }
> }
> --------------------------------------------
> --------- common.json ----------
> {
> "sysctl" : {
> "net.ipv4.ip_forward" : {
> "comment" : "Controls IP packet forwarding",
> "value" : "0"
> },
> "net.ipv4.conf.default.rp_filter" : {
> "comment" : "Controls source route verification",
> "value" : "1"
> }
> ...
> ...
> }
> -------------------------------------
>
> Where it becomes difficult is trying to then incorporate pure Fact data to
> influence or modify these decisions.
>
> Lets say that I actually get back 20 keys of sysctl data, one of those is
> 'vm.swappiness'. Most of my nodes have a value of '10', but lets say
> hypothetically that I have a small set of nodes that require a different
> value because of the amount of RAM available in the machine (a decision
> needs to be made based on hardware, not business logic). This is purely a
> Fact. Introducing another level of hierarchy for Fact 'memorytotal' is a bit
> silly in this case.
>
> The sysctl class looks roughly like this:
>
> ------- sysctl.pp ----------
> class sysctl {
> $sysctl_hash = hiera_hash('sysctl')
> create_resources('sysctl', $sysctl_hash)
> }
> ------------------------------
>
> I love that simplicity, however it's difficult to introduce edge cases that
> modify the data retrieved from Hiera based on Facts. Class inheritance won't
> work because create_resources() seems to insert into the catalog in an
> uninheritable way - bug report or fixable with Ruby DSL perhaps? Filling
> this class full of "if ($fact) modify hash" to munge the data pulled from
> Hiera seems dirty too.
>
> There may be no elegant solution and as you say, 80-90% may have to do.
>
> -Luke
>
>
> On 11/05/12 16:53, Gary Larizza wrote:
>
> 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+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> 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.
>
>
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
--
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.
