On Monday, December 16, 2013 9:53:49 AM UTC-6, Bilco105 wrote:
>
> Hi,
>
> I'm trying to do something with Hiera, whereby the 'default' configuration
> for a class is within it's role/profile manifest, which can then be
> overridden on a node specific basis by hiera.
>
> As an example;
>
> class profile::base {
> class { '::ntp':
> servers => ['a', 'b', 'c', 'd']
> }
> }
>
> node 'blah.com' {
> include profile::base
> }
>
> hieradata/nodes/blah.com.yaml:
> ---
> ntp::servers:
> - 0.uk.pool.ntp.org
> - 1.uk.pool.ntp.org
>
> However, I've noticed that hiera's behaviour seems to be that if a
> parameter is set like I do for the ntp::server param in the ntp class, it's
> not looked up (all the other NTP params are looked up in hiera, except for
> servers). Whereas if I just do:
>
> class profile::base {
> class { '::ntp': }
> }
>
> The server parameter is now looked up from hiera.
>
> Is this intended behaviour?
>
>
Yes. If you specify a class parameter value in a parameterized-style class
declaration then that value overrides anything available from hiera. Hiera
data, in turn, overrides any default value set in the class definition:
class ntp ($servers = ['e', 'f', 'g']) {
# stuff
}
If you want site defaults that can be overridden for special nodes, then
put the site defaults at a lower-priority level of your data hierarchy
instead of in a class declaration. Such hierarchical data are what hiera
is all about.
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/a1580d2f-77b8-4250-8fdc-3ecc46278d48%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
