On Thursday, April 28, 2016 at 3:03:44 PM UTC-5, Omen Wild wrote:
>
> I am looking for a way to pass "arguments" through multiple includes into
> a subclass. Situation is like this:
>
> ----- Begin code -----
> node 'a-file-server.ucdavis.edu' {
> include physicsnode
> }
>
> class physicsnode {
> include baseclass
>
> include ucdpuppet::kerberos
> }
>
> class ucdpuppet::kerberos {
> ...
> include ucdpuppet::kerberos::config
> ...
> }
>
> class ucdpuppet::kerberos::params inherits ucdpuppet::params {
> case $::osfamily {
> 'Debian', 'RedHat' : {
> $krb5_conf_path = '/etc/krb5.conf'
> $krb5_keytab_path = '/etc/krb5.keytab'
> }
> }
> ...
> }
>
> class ucdpuppet::kerberos::config inherits ucdpuppet::kerberos::params {
> file {$ucdpuppet::kerberos::params::krb5_conf_path :
> source => 'puppet:///modules/ucdpuppet/kerberos/krb5.conf'
> }
> }
> ----- End code -----
>
> The problem is that a-file-server.ucdavis.edu is a special snowflake
> and requires a different krb5.conf file. I could build that knowledge
> into ucdpuppet::kerberos::params based on the fqdn, but burying the
> info like that really bugs me. I would like some way to define that in
> the node definition and be able to pull that out in
> ucdpuppet::kerberos::config.
>
>
This sort of thing is Hiera's bread & butter. That would be a home run if
you were already using parameterized classes and automated data binding,
but Hiera does not depend on that -- you can use it directly via the hiera()
<https://docs.puppet.com/puppet/latest/reference/function.html#hiera>
function. It might look something like this:
class ucdpuppet::kerberos::config {
include 'ucdpuppet::kerberos::params'
# look up a value for $conf_path in Hiera; fall back to
# $ucdpuppet::kerberos::params::krb5_conf_path if Hiera
# doesn't otherwise provide a value
$conf_path = hiera('ucdpuppet::kerberos::config::conf_path',
$ucdpuppet::kerberos::params::krb5_conf_path)
file {$conf_path :
source => 'puppet:///modules/ucdpuppet/kerberos/krb5.conf'
}
}
That does require that you set up an Hiera data store
<https://docs.puppet.com/hiera/latest/hierarchy.html>, but if it were
limited to serving only what you describe, then that would comprise just
two small YAML files.
Note that the code you present appears to be using class inheritance
needlessly, and therefore inappropriately. There are only two good reasons
for using class inheritance in Puppet:
1. To perform resource overrides on resources declared by the parent
class (or by a more distant ancestor)
2. To ensure that class variables of the parent class are available for
use as class parameter defaults in the child class.
You do not need class inheritance for any other reason, and reason (1) is
these days not much exercised, as class parameterization and automated data
binding have eclipsed it as the preferred approach and the one recommended
by Puppet, Inc.. My example presents the alternative: simply to include
classes whose variables or resources you rely upon, but that you do not
need for class parameter defaults.
Note also that there is nothing special to Hiera about the internal
structure of data keys, but Puppet's automated data binding subsystem does
generate keys systematically. You're not using automated data binding, but
the key I chose in my example is the one that ADB would use for
$ucdpuppet::kerberos::config::conf_path if it were a class parameter
instead of an ordinary class variable. You might find that convenient if
you ever decided to start using ADB in your code base.
John
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/77c7b1b6-d5a5-42b9-967b-59faff5d78da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
