On Sun, Jun 27, 2010 at 12:48 AM, Al @ Lab42 <lab42...@gmail.com> wrote:
>
>
> On 27 Giu, 09:02, Douglas Garstang <doug.garst...@gmail.com> wrote:
>> I've been struggling with puppet variable scope all day, well, for
>> several months actually.
>>
>> I think I have pretty simple requirements. For any given node, I want
>> to be able to set a series of variables and include a set of classes,
>> based on three different aspects of a node, being physical location,
>> operating system, and function. If I try and do this with classes, I
>> find that variables set in a class included from a node, are not
>> visible to other classes included from that node.
>>
>> node 'node1.fr.xxx.com' {
>> include facility::sjc
>> include ldap::client
>>
>> }
>>
>> In this example, variables defined in facility::sjc are not visible in
>> ldap::client (in this case, it would be the IP address of the local
>> LDAP server).
>>
>> Another approach is to do everything with node inheritance, but in
>> order to model these three functions, you end up with nodes with names
>> like sjcDellBootServer or nycVmwareBootServer, which is just plain
>> stupid.
>
> Node names don't need to adapt to inheritance's logic.
> You can do something like:
> node sjc {
> ldap_server="10.10.10.10"
> }
>
> node 'node1.fr.xxx.com' inherits sjc {
> include ldap::client
> }
>
> When using nodes' inheritance the only real thing you've to care about
> is to define variables BEFORE including any class.
> So at the end it's better to include classes only in the node that
> defines your host nad never in the "intermediary" nodes that can
> represent facilities, networks or whatever.
>
> On the other way, this also should work, if you want to define your
> variables in a class:
>
> class ldap::client {
> include facility::sjc
>
> do_something with "${facility::ldap_server}" in this class
>
> BUT if you need to use "${facility::ldap_server}" in a template you
> should reassing it to a local variable (dunno if the problem is the
> colon or whatever I just found the problem and made a quick fix with
> somehting like):
> $my_ldap_server="${facility::ldap_server}"
>
> and use $my_ldap_server in the template.
>
> }
Al,
thanks for the examples and such. Your using pretty simplistic
examples, and I'm sorta beyond that point. Everything you said makes
sense, and is true. Trying to do a more complex implementation falls
apart though due to puppet's scoping issues.
The problem with doing something with "${facility::ldap_server}" is
that it should really be called "${facility::sjc::ldap_server}", and
when you do that, you completely destroy the whole point of
inheritance. The ldap client module itself should not directly
reference the "${facility::sjc::ldap_server}" variable, otherwise I
would see one ldap module for each facility!
Doug
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
