Hi All!
We've been long-time users of puppet (opensource). A lot of our
home-grown modules were written to use direct hiera() calls (and before
that extlookup()) for loading config. Because of prior limitations
with class parameters, we also mostly avoided parameterized classes and
class inheritance.
Since I converted my site from puppet 3.8.7 to puppetserver 5.x and
puppet-agent 5.3.x, and converted us from hiera 3.x to hiera 5.x, a lot
of the "old ways" we were doing things can and should be modernized. For
example, I'm embarking on a project to convert all deprecated direct
hiera() calls to use lookup() instead, but before I do that I can also
greatly reduce the number of direct lookup() calls by making better use
of automatic parameter loading for classes, where appropriate.
One area where I've never found a good solution is class parameters that
depend on the value of other class parameters, especially when we want to
provide reasonable defaults for both but we also want to allow overriding
one or both of the parameters.
Here's an example:
modules/sandbox/manifests/init.pp:
#
# This module exists only to serve as a sandbox where we can experiment with
# puppet code.
#
class sandbox(
Enum['typeA', 'typeB', 'combined'] $server_type = 'combined',
String $service_name =
$::sandbox::params::service_name,
) inherits ::sandbox::params {
notice("sandbox initialized.\n")
notice("\$server_type = ${server_type}\n")
notice("\$service_name = ${service_name}\n")
}
modules/sandbox/manifests/params.pp:
#
# a 'sandbox' class for the params pattern.
#
class sandbox::params {
$_server_type_actual = $::sandbox::server_type
case $_server_type_actual {
'combined': {
$service_name = 'sandbox-typeA+typeB'
}
'typeA': {
$service_name = 'sandbox-typeA'
}
'typeB': {
$service_name = 'sandbox-typeB'
}
default: {
fail("\n\nsandbox::server_type must be one of: combined, typeA, typeB\n")
}
}
}
Hopefully the *intent* is relatively clear: provide an intelligent default
value for $service_name based on what the value is for $server_type, but
allow our "intelligent default" value to be overridden. If
'sandbox::server_type' is set to 'typeB' in our hiera hierarchy, I want
the *default* value for 'sandbox::service_name' to become 'sandbox-typeB'.
If the person configuring the machine needs to override that too, they
should be able to, but setting just the first setting should provide
suitable defaults for the others.
This doesn't work, because there's a chicken-or-the-egg problem here.
Class sandbox inherits from sandbox::params to follow the "params
pattern", so settings in the parent class end up depending upon on
parameters to the child class.
Assuming I don't have any need to support old versions of puppet (anything
before 5.x), what's the current best practice for doing this?
Thanks,
Tim
--
Tim Mooney tim.moo...@ndsu.edu
Enterprise Computing & Infrastructure 701-231-1076 (Voice)
Room 242-J6, Quentin Burdick Building 701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164
--
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/alpine.SOC.2.20.1806111713120.8924%40dogbert.cc.ndsu.NoDak.edu.
For more options, visit https://groups.google.com/d/optout.
