On May 25, 10:12 am, Mathias Klette <mathias.kle...@profitbricks.com>
wrote:
> Hi,
>
> I'm wondering in which order puppet qualifies variables when using default
> values at the same time.
>
> I'm trying to set this up for a general ntp-class serving ntp.conf for
> server and client-mode. There is a general params-subclass which defines my
> defaults. One of the variables depends on a variable defined in the same
> class (ntp::params::ntp_server depends on ntp::params::ntp_mode). These
> values are then used to compile ntp.conf.
> All is fine, as long as I do not want to override the variable.
Then all is fine, because you do not ever override
$ntp::params::ntp_mode. Indeed, you cannot do so -- Puppet subclasses
can override only *resource parameters* of resources declared by their
parent class, nothing else.
> I see
> correct servers and options ('broadcast') used in the generated ntp.conf.
> But when I try to reset the variable 'ntp_server' from outside the class
> (i.e. class becomes included in a node definition) only the template uses
> my overwritten value, but not my conditional placed inside 'ntp::params'.
Puppet variables can be set only once per catalog. They cannot be
"reset". Variables with the same simple name can be declared in
different scopes, but these are different variables, even when the
scopes overlap.
> ## manifests/nodes.pp
> node /^(mgmt).*/ {
> class { 'ntp' :
> ntp_mode => 'client',
> }
> ...
>
> }
>
> ## modules/ntp/manifests/params.pp
> class ntp::params {
[...]
> $ntp_mode = $::hostname ? {
> /^(mgmt).*/ => 'server',
> default => 'client',
> }
That $ntp_mode is $::ntp::params::ntp_mode.
> $ntp_server = $ntp_mode ? {
> server =>
> ['ptbtime1.ptb.de','ptbtime2.ptb.de','ptbtime3.ptb.de','1.debian.pool.ntp.org'],
> client => ['ntp1','ntp2'],
> default => undef,
> }
That conditional tests $::ntp::params::ntp_mode (not $::ntp::mode,
which you declare elsewhere, and which is not even in scope here).
> $ntp_broadcast = $::broadcast
>
> }
> ## modules/ntp/manifests/init.pp
> class ntp (
> $ntp_mode = $::ntp::params::ntp_mode,
The $ntp_mode declared there is $::ntp::mode, not
$::ntp::params::ntp_mode. Indeed,it cannot be the latter, for then it
would be defined in terms of itself. As mentioned above, $::ntp::mode
has no effect on $::ntp::params::ntp_server.
> $ntp_server = $::ntp::params::ntp_server,
> $ntp_broadcast = $::ntp::params::ntp_broadcast,
> ) inherits ntp::params {
> ...
> file { $config_name :
> ensure => file,
> path => $config_name,
> owner => $config_owner,
> group => $config_group,
> mode => $config_mode,
> content => template($config_content),
> }
[...]
> So, I'd like to know is there any way to let puppet re-evaluate
> ntp_server-assignment in ntp::params? Is that qualification intended or may
> I hit a bug here?
Puppet never re-evaluates anything in the course of a catalog
compilation. It has no reason to do so unless your manifests make
contradictory declarations, and in that case it errors on the
contradiction instead. Puppet is behaving exactly as intended.
If you want to perform logic based on the parameters of class ntp,
then that logic must appear in class ntp or in a class that (thereby)
depends on class ntp. It cannot appear in classes that ntp itself
depends on.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
