I recommend taking a look at R I Pienaar's alternative extlookup
implementation. It supports YAML in addition to csv which allows for the
full range of available variable types to be pulled in from external
sources. I've combined this with a YAML-based ENC to put all variables for
a single node into one YAML file. It's working well for me.
On Aug 1, 2011 2:20 PM, "jcbollinger" <john.bollin...@stjude.org> wrote:
>
>
> 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.
>
--
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.
