On Tue, Jul 2, 2013 at 3:27 PM, Eric Sorenson
<[email protected]> wrote:
> - Reading through Wil's example is really interesting because it also
> touches on module reusability and module APIs. Are others on the thread in a
> similar situation, where you need to compose/abstract common config
> parameters to reduce duplication across your site data hierarchy? (And Wil,
> is there a reason you can't just do that 'ldap_login_server_uris' mapping at
> class declaration time rather than putting the lookups into the class
> definitions themselves?)
Let me make sure I understand what you are suggesting. When I declare
the class, I expressly use the hiera lookup to provide the appropriate
parameter for the class:
modules/nss_pam_ldapd/manifests/config.pp:
class nss_pam_ldapd::config {
$server_uris = hiera('nss_pam_ldapd::config::server_uris', ...), #
maybe kill explicit hiera() here for simplicity
...
}
manifests/site.pp:
node foo {
include nss_pam_ldapd
class { 'nss_pam_ldapd::config':
server_uris => hiera('ldap_login_server_uris')
}
}
Sure, you can do that, but declaring the class is a good deal messier
-- with the hiera-internal reference it would be just "include
nss_pam_ldapd". From what I understand, practices are evolving towards
simplifying node declaration by putting more of the complexity in
hiera. If so, then it seems better to appeal to people's
self-interest/laziness by making it easy to do it that way.
Wil
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
