I found a workaround by using distinct array names for default/specific
sysctl values and requiring the default class in the role specific class...
but I hoped there was a clever way. Anyone ?
class sysctl::defaults {
create_resources( sysctl::config::defaults,
hiera('sysctl_settings_defaults') )
}
define sysctl::config::defaults ($value) {
augeas { "sysctl_${name}":
context => "/files/etc/sysctl.conf",
lens => "sysctl.lns",
incl => "/etc/sysctl.conf",
changes => [ "set ${name} ${value}" ],
}
}
class sysctl::specific {
require sysctl::defaults
create_resources( sysctl::config::specific,
hiera('sysctl_settings_specific') )
}
define sysctl::config::specific ($value) {
augeas { "Sysctl_${name}":
context => "/files/etc/sysctl.conf",
lens => "sysctl.lns",
incl => "/etc/sysctl.conf",
changes => [ "set ${name} ${value}" ],
}
}
On Saturday, April 7, 2012 10:18:55 AM UTC-4, Jeff 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.
>
> 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.
>
> So here’s the hiera config :
>
> ---
>
> :hierarchy:
>
> - %{fqdn}
>
> - %{os}
>
> - %{role}
>
> - %{datacenter}
>
> - common
>
> :backends:
>
> - yaml
>
> :yaml:
>
> :datadir: '/etc/puppet/hieradata'
>
>
>
> The common sysctl are in common.yaml:
>
> classes:
>
> - sysctl
>
> sysctl_settings:
>
> net.ipv4.ip_forward:
>
> value: 0
>
> kernel.randomize_va_space:
>
> value: 1
>
> net.ipv4.conf.all.send_redirects:
>
> value: 0
>
>
>
> The more specific and possibly overriding parameters are in role-ap.yaml:
>
> classes:
>
> - sysctl
>
>
>
> sysctl_settings:
>
> vm.swapiness:
>
> value: 0
>
> net.ipv4.ip_forward:
>
> value: 1
>
>
> The sysctl wrapper module :
>
>
> class sysctl {
>
> create_resources( sysctl::config, hiera('sysctl_settings') )
>
> }
>
> define sysctl::config ($value) {
>
> augeas { "sysctl_${name}":
>
> context => "/files/etc/sysctl.conf",
>
> lens => "sysctl.lns",
>
> incl => "/etc/sysctl.conf",
>
> changes => [ "set ${name} ${value}" ],
>
> }
>
> }
>
> 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 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?
>
> Thanks to all,
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/3cRxsuVpSrcJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
