Puppet users - May 2012 - Variable qualification: ordering or reset possible?

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. 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''.

## /etc/ntp.conf: Without override (ntp_mode = server)
...
server ptbtime1.ptb.de
server ptbtime2.ptb.de
server ptbtime3.ptb.de
server 1.debian.pool.ntp.org


broadcast 10.254.1.255
...

## /etc/ntp.conf: With override (ntp_mode = client)
server ptbtime1.ptb.de      <-- servers should only show ntp1, ntp2
server ptbtime2.ptb.de
server ptbtime3.ptb.de
server 1.debian.pool.ntp.org


                          <-- broadcast is missing, template knows about 
overwritten variable
...


My manifests/templates look like this:

## manifests/site.pp
include modules.pp
include nodes.pp
...

## manifests/modules.pp
import ''ntp''
...

## manifests/nodes.pp
node /^(mgmt).*/ {
  class { ''ntp'' :
    ntp_mode => ''client'',
  }
  ...
}

## modules/ntp/manifests/params.pp
class ntp::params {
...
  $config_content = $::os ? {
    default => ''ntp/ntp.conf.default.erb''
  }

  $ntp_mode = $::hostname ? {
    /^(mgmt).*/   => ''server'',
    default          => ''client'',
  }

  $ntp_server = $ntp_mode ? {
    server  => 
[''ptbtime1.ptb.de'',''ptbtime2.ptb.de'',''ptbtime3.ptb.de'',''1.debian.pool.ntp.org''],
    client  => [''ntp1'',''ntp2''],
    default => undef,
  }

  $ntp_broadcast = $::broadcast
}

## modules/ntp/manifests/init.pp
class ntp (
  $ntp_mode                 = $::ntp::params::ntp_mode,
  $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),
  }
...

## modules/ntp/templates/ntp.conf.default.erb
...
 <%- ntp_server.each do |host| -%>
server <%= host %>
<% end -%>

<%- if ntp_mode.to_s == ''server'' then %>
broadcast <%= ntp_broadcast %>
<%- end %>
...


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?

Thanks in advance
Mathias

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/Adp7TCkctpgJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.