On Jun 27, 8:25 pm, Douglas Garstang <doug.garst...@gmail.com> wrote:
> 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.
>
> That's awful. If you can't build an inheritance tree from generic to
> specific, and assign variables at each step, that's a loss of a lot of
> functionality, and just about makes everything impossible.
You misunderstood. You can assign variables at each "step" in the
inheritance tree, and redefine them at more specific node steps.
It's just important to include whatever classes you need in your node
at the end of the inheritance tree, at the host-node level.
You could actually include classes in step-nodes only if they don't
use variables that might be defined (or redefined) at more specific
steps. That's why it's safer to include classes at the end, at host-
node level and define your variables, according to whatever logic you
need, in the nodes inheritance tree.
> And, even if I do that, only including classes in the final node...
>
> class A {
> $var = 1
>
> }
>
> class B {
> < do something with $var >
>
> }
>
> node A {
> include class A
> include class B
>
> }
>
> This doesn't work! But, it's doing what you suggested. Class B does
> not have access to $var, because it's out of scope. This is exactly
> what I want to do. I want to define an LDAP server variable in class
> A, and then use it in class B.
>
> Doug
You can do something like:
class B {
include A
< do something with ${A::var}
}
or, cleaner, define all your variables in a separated subclass that
can be included by every class that needs these variables (included
the same A class):
class B {
include A::params
< do something with ${A::params::var}
}
class A {
include A::params
# These A variables can be shared by other classes that include
A::params
}
Would this work?
Al
--
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.
