On Wednesday, September 5, 2012 5:09:52 AM UTC-5, renaud wrote:
>
> Hello all,
>
> I know that execution order is not guaranteed within a scope without
> explicitly declaring dependencies.
> However I've always been able to set variables in classes, and expect them
> to be used properly in templates that I declare in a File statement in the
> same class.
>
Indeed you should be able to rely on that, for the correct definition of
"properly".
> It looks like I came across a problem with this yesterday :
>
> My class contains :
>
> $master_port = 6379
> $master_host = $hostname ? {
> /(stage|live)-xx([a-d])-redis1/ => "$1-yy$2-redis1",
> default => false,
> }
>
> file { "/etc/redis/redis.conf":
> ensure => file,
> owner => "root",
> group => "root",
> mode => "0644",
> content => template("redis/redis.conf.erb"),
> }
>
> And redis.conf.erb contains :
>
> <% if master_host -%>
> slaveof <%= master_host %> <%= master_port %>
> <% end -%>
>
> When the hostname matches the regexp, here's what I get in redis.conf
> depending on how I run puppet :
>
> - If I run puppet masterless using "puppet apply testing.pp" (with
> testing.pp being a simple manifest that just include the module that
> contains the class above) :
> "slaveof live-yya-redis1 6379"
> This is fine
> - But if I run puppet through "puppet agent --test", with the exact same
> manifest on the puppetmaster as locally, I get this :
> "slaveof 6379"
>
> So, it looks like in the second case the master_host variable is
> definitely set (otherwise the if statement in the .erb would exit), but set
> to an empty string, while the other master_port variable, which is defined
> right next to it in the manifest, works fine !
>
> Any idea why that should be ?
>
The Puppet templating docs recommend referring to DSL variables via Ruby
class variables, so as @master_host and @master_port in your case.
Referring to them via local variables (as your template does) will often
work, but it can fail in interesting ways if your variables happen to have
the same name as in-scope local variables of the Puppet application. I
think that's what has happened to you.
I suspect that the conflicting master_* variables belong to the puppet
master code (makes sense), so it is plausible that they are not in scope
when you apply your class via "puppet apply", whereas they are in scope
when the template is processed by the master in order to service "puppet
agent".
John
--
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/-/AbYxW9qErd0J.
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.
