On Aug 1, 6:37 am, Martijn Grendelman <mart...@iphion.nl> wrote:
[...]
> In classes that have been defined in the top scope (imported in site.pp),
> I can use the fully qualified names ($::somevar). That results in the
> correct value, and it doesn't generate any warnings about dynamic scoping.
>
> However, inside modules, this doesn't work. I get empty values when I try
> that. For example:
>
> In nodes.pp:
>
> node basenode {
> $syslocation = "Server room"
>
> }
>
> node testserver inherits basenode {
> $syslocation = "Martijn's office"
>
> }
>
> In modules/snmp/manifests/init.pp:
>
> notify { "System location: $syslocation": }
> notify { "System location qualified: $::syslocation": }
>
> results in:
>
> notice: System location qualified:
> notice: /Stage[main]/Snmp/Notify[System location qualified: ]/message:
> defined 'message' as 'System location qualified: '
>
> notice: System location: Martijn's office
> notice: /Stage[main]/Snmp/Notify[System location: Martijn's
> office]/message: defined 'message' as 'System location: Martijn's office'
>
> The 'dynamic' name works (but gives a warning), the fully-qualified name
> doesn't work. The use of curly braces ${::syslocation} doesn't make any
> difference.
Well that's something I didn't know before, but it appears to mesh
well with Vagn's recent observations about preparing for Puppet 2.8:
http://groups.google.com/group/puppet-users/browse_thread/thread/6f1e087a6daba343
>[I wrote:]
> > 3) There is another built-in alternative to dynamically-scoped
> > variables: the extlookup() function. Using extlookup() to retrieve
> > data for your resources can allow you to minimize the number of
> > parameters you need to pass, or even to avoid class parameterization
> > altogether. I think this is a great way to go, but Puppetlabs's style
> > guide disfavors it.
>
> The big question here is: would that be future-proof??
Considering that Puppet supports user-defined functions, and that
extlookup() even started out as such, I think it's reasonably safe to
expect that you could continue to use extlookup() at least into the
mid-term future. Even if Puppetlabs were to yank extlookup() back out
of the standard distribution, you could put it back in as a custom
function at your site. The source is available and freely reusable,
of course.
Extlookup() has the added advantage for you that its data model maps
very cleanly onto the node taxonomy you described (global defaults,
internal / external, specific node). From that angle, at least, it
should be straightforward to convert your existing manifest design to
use extlookup().
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.
