thr3ads.net - Puppet users - [Puppet Users] Puppet 2.7.1, variable scoping, best practices [Jun 2011]

If this information is useful, please help other people find it:
Share via:

Martijn Grendelman

2011-Jun-30 11:15 UTC

[Puppet Users] Puppet 2.7.1, variable scoping, best practices

Hi,

Having installed Puppet 2.7.1 on my testserver yesterday, I am now bugged
by log messages, that tell me not to use dynamic variable lookups:

Jun 29 13:31:09 os1 puppet-master[31910]: Dynamic lookup of
$ssh_permitrootlogin at /etc/puppet/templates/etc/ssh/sshd_config.erb:28
is deprecated.  Support will be removed in Puppet 2.8.  Use a
fully-qualified variable name (e.g., $classname::variable) or
parameterized classes.

Now, I have been reading up on variable scoping and trying to figure out
how to rewrite my manifests to embrace best practices, but I am confused
on how to proceed, and I can''t really find any working examples, so I
turn
here for help.

My current setup is something like this:


node basenode {
    $somevar      = "defaultvalue"
    $someothervar = "anotherdefault"
}

node internal inherits basenode {
    $someothervar = "internaloverride"
}

node external inherits basenode {
}

node myinternalserver inherits internal {
    $somevar = "nodeoverride"
    include generic
}

node someexternalserver inherits external {
    include generic
}

...another 40 node definitions, inheriting either internal or external...

class generic {
    include someclass
    include somemodule::anotherclass
    ...
    include <a whole bunch of other classes that every node needs>
}


In any class or module I use $somevar and $someothervar as I please, and I
understand that this a) is not a recommended practice and b) will stop
working in Puppet 2.8.

So, what should I do?

Switching to parameterized classes sounds nice, but that would mean that
the ''generic'' class would have to get /every/ variable I use
as a
parameter and pass it on to subsequent classes where needed. That sounds
incredibly clumsy to me.

In http://docs.puppetlabs.com/guides/scope_and_puppet.html I read:

  "If you’re using dynamic scope to share resource defaults, there’s no
way around it: you’ll have to repeat yourself in each file that the
defaults apply to."

Is this what''s biting me here? Well, this sounds like something I can
live
with, after all: it''s not the default values I care about,
it''s the
overriding values.

Further, it states:

  "If you need to apply resource defaults more broadly, you can still set
them at top scope in your primary site manifest. If you need the resource
defaults in a class to change depending on where the class is being
declared, you need parameterized classes."

And we''re back at parameterized classes. And what does ''top
scope'' mean
exactly? I assume that would be in ''site.pp'', outside any
class or node
definition?

To make a long question short: what is the recommended way to override
values for certain nodes or groups of nodes (by inheritance)? And I''d
/really/ prefer to do that without having to pass on each and every value
as a parameter to the next included class...

Best regards,
Martijn.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

vagn scott

2011-Jun-30 18:26 UTC

head link

Re: [Puppet Users] Puppet 2.7.1, variable scoping, best practices

I''m doing something similar with class inheritance,
rather than node inheritance.

  In http://docs.puppetlabs.com/guides/scope_and_puppet.html it says:

         In effect, all variables will be either strictly local or strictly
         global. The one exception will be derived classes, which will 
continue
         to consult the scope of the base class they inherit from.

I take this to mean that foo() below won''t get anything from
it''s enclosing class since it is not inheriting from that class.
This change breaks everything non-trivial I''ve written lately.

But, wait!  About the postfix example it says

         postfix::custom’s chain of parent scopes is

                 postfix::custom < postfix < base < top-scope

Well, that''s not too bad.  Everything should keep working.
So, a better statement would be:

         All variables will be either strictly local or strictly
         global. The two exceptions will be derived classes, which will 
continue
         to consult the scope of the base class they inherit from,
         and included classes that can see variables from the including 
class.

Tell me this is still going to work:


class default {
     $somevar      = "defaultvalue"
     $someothervar = "anotherdefault"
         # 50 other items
}

define foo($a, $b, $c=z) {

         # uses somevar and someothervar

}

class local_foo1 inherits default {
     $someothervar = "internaloverride"

     foo { "blah":   a => "x", b => "y" }
     foo { "fooey":  a => "x2", b => "y2" }

}

class local_foo2 inherits default {
     $someothervar = "internaloverride2"

     foo { "yuck":   a => "x3", b => "y" }

}

node baz {

     class ( "local_foo1": }
     class ( "local_foo2": }

}

and if it won''t continue to work, how about an explicit
inherits for scopes and lookup order?

define foo($a, $b, $c=z) {
         $inherits = [
                 Parent[2],               # parent and grandparent
                 #global,                 # uncomment if you want global
                 Class[ "site_params2" ]  # in lieu of global
         ]
         # uses somevar and someothervar
}

About this:

         But this is not a bad thing! Resource defaults are really just
         code compression, and were designed to make a single file of
         Puppet code more concise. By making sure your defaults are always
         on the same page as the resources they apply to, you’ll make
         your code vastly more legible and predictable.

"Just code compression"?  No, defaults is an expression of DRY:
Don''t Repeat Yourself.  How are we supposed to keep our code DRY
under this new regime?


Aside:

I never liked puppet''s use of the term include.  Maybe because
I''m a C
programmer. In C/C++ include is a textual interpolation, similar to
string interpolation.  But, for puppet:

         include something

I have to mentally translate that to

         use something
         something.set_parent_scope(this)

Which, if I''m reading things right, won''t be changing to

         use something
         something.set_parent_scope(nil)



Anyway, looks like I''ll be testing 2.7 soon.

-- 
vagn

On 06/30/2011 07:15 AM, Martijn Grendelman wrote:> Hi,
>
> Having installed Puppet 2.7.1 on my testserver yesterday, I am now bugged
> by log messages, that tell me not to use dynamic variable lookups:
>
> Jun 29 13:31:09 os1 puppet-master[31910]: Dynamic lookup of
> $ssh_permitrootlogin at /etc/puppet/templates/etc/ssh/sshd_config.erb:28
> is deprecated.  Support will be removed in Puppet 2.8.  Use a
> fully-qualified variable name (e.g., $classname::variable) or
> parameterized classes.
>
> Now, I have been reading up on variable scoping and trying to figure out
> how to rewrite my manifests to embrace best practices, but I am confused
> on how to proceed, and I can''t really find any working examples,
so I turn
> here for help.
>
> My current setup is something like this:
>
>
> node basenode {
>      $somevar      = "defaultvalue"
>      $someothervar = "anotherdefault"
> }
>
> node internal inherits basenode {
>      $someothervar = "internaloverride"
> }
>
> node external inherits basenode {
> }
>
> node myinternalserver inherits internal {
>      $somevar = "nodeoverride"
>      include generic
> }
>
> node someexternalserver inherits external {
>      include generic
> }
>
> ...another 40 node definitions, inheriting either internal or external...
>
> class generic {
>      include someclass
>      include somemodule::anotherclass
>      ...
>      include<a whole bunch of other classes that every node needs>
> }
>
>
> In any class or module I use $somevar and $someothervar as I please, and I
> understand that this a) is not a recommended practice and b) will stop
> working in Puppet 2.8.
>
> So, what should I do?
>
> Switching to parameterized classes sounds nice, but that would mean that
> the ''generic'' class would have to get /every/ variable I
use as a
> parameter and pass it on to subsequent classes where needed. That sounds
> incredibly clumsy to me.
>
> In http://docs.puppetlabs.com/guides/scope_and_puppet.html I read:
>
>    "If you’re using dynamic scope to share resource defaults, there’s
no
> way around it: you’ll have to repeat yourself in each file that the
> defaults apply to."
>
> Is this what''s biting me here? Well, this sounds like something I
can live
> with, after all: it''s not the default values I care about,
it''s the
> overriding values.
>
> Further, it states:
>
>    "If you need to apply resource defaults more broadly, you can still
set
> them at top scope in your primary site manifest. If you need the resource
> defaults in a class to change depending on where the class is being
> declared, you need parameterized classes."
>
> And we''re back at parameterized classes. And what does
''top scope'' mean
> exactly? I assume that would be in ''site.pp'', outside any
class or node
> definition?
>
> To make a long question short: what is the recommended way to override
> values for certain nodes or groups of nodes (by inheritance)? And
I''d
> /really/ prefer to do that without having to pass on each and every value
> as a parameter to the next included class...
>
> Best regards,
> Martijn.
>
>    
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

jcbollinger

2011-Jul-01 14:01 UTC

head link

[Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices

On Jun 30, 6:15 am, Martijn Grendelman <mart...@iphion.nl>
wrote:> Hi,
>
> Having installed Puppet 2.7.1 on my testserver yesterday, I am now bugged
> by log messages, that tell me not to use dynamic variable lookups:
>
> Jun 29 13:31:09 os1 puppet-master[31910]: Dynamic lookup of
> $ssh_permitrootlogin at /etc/puppet/templates/etc/ssh/sshd_config.erb:28
> is deprecated.  Support will be removed in Puppet 2.8.  Use a
> fully-qualified variable name (e.g., $classname::variable) or
> parameterized classes.
>
> Now, I have been reading up on variable scoping and trying to figure out
> how to rewrite my manifests to embrace best practices, but I am confused
> on how to proceed, and I can''t really find any working examples,
so I turn
> here for help.
>
> My current setup is something like this:
>
> node basenode {
>     $somevar      = "defaultvalue"
>     $someothervar = "anotherdefault"
>
> }

[...]

> In any class or module I use $somevar and $someothervar as I please, and I
> understand that this a) is not a recommended practice and b) will stop
> working in Puppet 2.8.
>
> So, what should I do?

It''s not actually clear to me whether "top level" includes
inside node
declarations, but IMHO it should.  If it does, and if you do not rely
on defining different values for $somevar or $someothervar inside your
classes (see below), then you should be able to solve your problem by
changing all appearance of $somevar and $someothervar to $::somevar
and $::someothervar (i.e. use their fully-qualified names as the
warning suggests).  It should be pretty easy to test whether that
works for you.

> Switching to parameterized classes sounds nice, but that would mean that
> the ''generic'' class would have to get /every/ variable I
use as a
> parameter and pass it on to subsequent classes where needed. That sounds
> incredibly clumsy to me.

As regulars here will know, I am not a big fan of parameterized
classes.  Puppetlabs likes them, and pushes them, but I think they are
rarely the best tool for the job.  Perhaps the thing that they are
most appropriate for, however, is avoiding dynamic scoping.  More on
that below.

You are right that for your manifest design, solving the problem via
class parameterization would require your Class["generic"] to be
parameterized with all the variables it uses directly plus all those
needed by the classes it includes.  I think this is one reason that
Puppetlabs'' style guide now recommends avoiding classes including
other classes.  Once your manifests become complex enough that that is
painful, they suggest using an external node classifier.  If you don''t
buy in to parameterized classes, however, then that advice does not
stand up so well.

> Inhttp://docs.puppetlabs.com/guides/scope_and_puppet.htmlI read:
>
>   "If you re using dynamic scope to share resource defaults, there s
no
> way around it: you ll have to repeat yourself in each file that the
> defaults apply to."
>
> Is this what''s biting me here? Well, this sounds like something I
can live
> with, after all: it''s not the default values I care about,
it''s the
> overriding values.

Forgive me for being didactic:

In Puppet < 2.8.0, variables declared outside any class can be
overridden by declarations of the same variable name within classes.
Within a class that does so and any class it includes, recursively,
the variable''s unqualified name resolves to the class''s
definition,
not the top-level one.  Except that this nests, so that if an included
class also defines a variable having the same simple name, then it and
its included classes see *its* definition.  This is called "dynamic
scoping".

Dynamic scoping presents at least two problems:

1) When a class refers to externally defined variables by their simple
names, it is hard to know what definition of the variable you''re going
to get.  That''s not such a big deal, though, and it could even be
considered an advantage -- the external variables a class uses can be
considered de facto parameters for it.

2) Classes can be included multiple times, by more than one path, and
there is no guarantee that the values they see for unqualified
external variable names will be the same at each inclusion.  This can
result in unintended behavior, but the problem is not so much that
dynamic scoping is inherently bad, but rather that it facilitates poor
manifest design.

Parameterized classes address problem (1) by formalizing class
parameterization, and they address problem (2) by making it illegal to
include a parameterized class more than once (even with the same
parameters).  One of my main objections to parameterized classes is
that the latter is too far-reaching and constraining.

> Further, it states:
>
>   "If you need to apply resource defaults more broadly, you can still
set
> them at top scope in your primary site manifest. If you need the resource
> defaults in a class to change depending on where the class is being
> declared, you need parameterized classes."
>
> And we''re back at parameterized classes. And what does
''top scope'' mean
> exactly? I assume that would be in ''site.pp'', outside any
class or node
> definition?

Outside any class or node definition and inside site.pp or any
manifest ''import''ed by it is certainly top-level.  Surely
someone else
around here knows offhand whether anywhere else, such as inside node
definitions, is also top-level.  Or you can test: the fully-qualified
name of a top-level variable $somevar is $::somevar.

> To make a long question short: what is the recommended way to override
> values for certain nodes or groups of nodes (by inheritance)? And
I''d
> /really/ prefer to do that without having to pass on each and every value
> as a parameter to the next included class...

Things to consider:

1) I personally recommend avoiding deep node inheritance hierarchies.
In fact, I recommend no more than two levels to your node inheritance
tree.  This may or may not help with your present problem.

2) As I mentioned above, you may be able to just change to fully-
qualified variable names.  That would be quick and relatively
painless.

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.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

vagn scott

2011-Jul-01 17:10 UTC

head link

Re: [Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices

On 07/01/2011 10:01 AM, jcbollinger wrote:
> Parameterized classes address problem (1) by formalizing class
> parameterization, and they address problem (2) by making it illegal to
> include a parameterized class more than once (even with the same
> parameters).  One of my main objections to parameterized classes is
> that the latter is too far-reaching and constraining.
>
>
>    
The problem is context dependent classes.
The new rules intend to make it impossible to
write such classes, except where the context
is explicitly passed in the argument list.
> Things to consider:
>
> 1) I personally recommend avoiding deep node inheritance hierarchies.
> In fact, I recommend no more than two levels to your node inheritance
> tree.  This may or may not help with your present problem.
> 2) As I mentioned above, you may be able to just change to fully-
> qualified variable names.  That would be quick and relatively
> painless.
>    
Well, I will play with 2.7 this weekend with an eye toward
killing context dependencies in my manifests.  The question
is, are the dependencies necessary (and there are a lot of them),
or are they just a result of thinking in C?

Thanks for being didactic :-)

-- 
vagn

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Martijn Grendelman

2011-Aug-01 11:37 UTC

head link

Re: [Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices

Hi,

I am bringing back a topic that I started a month ago. Summer holidays
prevented me from following up on it back then, but they didn''t make
the
problem go away, unfortunately ;-)
>> Having installed Puppet 2.7.1 on my testserver yesterday, I am now
bugged
>> by log messages, that tell me not to use dynamic variable lookups:
>>
>> Jun 29 13:31:09 os1 puppet-master[31910]: Dynamic lookup of
>> $ssh_permitrootlogin at
/etc/puppet/templates/etc/ssh/sshd_config.erb:28
>> is deprecated.  Support will be removed in Puppet 2.8.  Use a
>> fully-qualified variable name (e.g., $classname::variable) or
>> parameterized classes.
>>
>> Now, I have been reading up on variable scoping and trying to figure
out
>> how to rewrite my manifests to embrace best practices, but I am
confused
>> on how to proceed, and I can''t really find any working
examples, so I turn
>> here for help.
>>
>> My current setup is something like this:
>>
>> node basenode {
>>     $somevar      = "defaultvalue"
>>     $someothervar = "anotherdefault"
>>
>> }
> 
> 
> [...]
> 
> 
>> In any class or module I use $somevar and $someothervar as I please,
and I
>> understand that this a) is not a recommended practice and b) will stop
>> working in Puppet 2.8.
>>
>> So, what should I do?
> 
> 
> It''s not actually clear to me whether "top level"
includes inside node
> declarations, but IMHO it should.  If it does, and if you do not rely
> on defining different values for $somevar or $someothervar inside your
> classes (see below), then you should be able to solve your problem by
> changing all appearance of $somevar and $someothervar to $::somevar
> and $::someothervar (i.e. use their fully-qualified names as the
> warning suggests).  It should be pretty easy to test whether that
> works for you.
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.
>> Switching to parameterized classes sounds nice, but that would mean
that
>> the ''generic'' class would have to get /every/
variable I use as a
>> parameter and pass it on to subsequent classes where needed. That
sounds
>> incredibly clumsy to me.
> 
> 
> As regulars here will know, I am not a big fan of parameterized
> classes.  Puppetlabs likes them, and pushes them, but I think they are
> rarely the best tool for the job.  Perhaps the thing that they are
> most appropriate for, however, is avoiding dynamic scoping.  More on
> that below.
> 
> You are right that for your manifest design, solving the problem via
> class parameterization would require your Class["generic"] to be
> parameterized with all the variables it uses directly plus all those
> needed by the classes it includes.  I think this is one reason that
> Puppetlabs'' style guide now recommends avoiding classes including
> other classes.  Once your manifests become complex enough that that is
> painful, they suggest using an external node classifier.  If you
don''t
> buy in to parameterized classes, however, then that advice does not
> stand up so well.
> 
> 
>> Inhttp://docs.puppetlabs.com/guides/scope_and_puppet.htmlI read:
>>
>>   "If you re using dynamic scope to share resource defaults, there
s no
>> way around it: you ll have to repeat yourself in each file that the
>> defaults apply to."
>>
>> Is this what''s biting me here? Well, this sounds like
something I can live
>> with, after all: it''s not the default values I care about,
it''s the
>> overriding values.
> 
> 
> Forgive me for being didactic:
> 
> In Puppet < 2.8.0, variables declared outside any class can be
> overridden by declarations of the same variable name within classes.
> Within a class that does so and any class it includes, recursively,
> the variable''s unqualified name resolves to the class''s
definition,
> not the top-level one.  Except that this nests, so that if an included
> class also defines a variable having the same simple name, then it and
> its included classes see *its* definition.  This is called "dynamic
> scoping".
> 
> Dynamic scoping presents at least two problems:
> 
> 1) When a class refers to externally defined variables by their simple
> names, it is hard to know what definition of the variable you''re
going
> to get.  That''s not such a big deal, though, and it could even be
> considered an advantage -- the external variables a class uses can be
> considered de facto parameters for it.
> 
> 2) Classes can be included multiple times, by more than one path, and
> there is no guarantee that the values they see for unqualified
> external variable names will be the same at each inclusion.  This can
> result in unintended behavior, but the problem is not so much that
> dynamic scoping is inherently bad, but rather that it facilitates poor
> manifest design.
> 
> Parameterized classes address problem (1) by formalizing class
> parameterization, and they address problem (2) by making it illegal to
> include a parameterized class more than once (even with the same
> parameters).  One of my main objections to parameterized classes is
> that the latter is too far-reaching and constraining.
> 
> 
>> Further, it states:
>>
>>   "If you need to apply resource defaults more broadly, you can
still set
>> them at top scope in your primary site manifest. If you need the
resource
>> defaults in a class to change depending on where the class is being
>> declared, you need parameterized classes."
>>
>> And we''re back at parameterized classes. And what does
''top scope'' mean
>> exactly? I assume that would be in ''site.pp'', outside
any class or node
>> definition?
> 
> 
> Outside any class or node definition and inside site.pp or any
> manifest ''import''ed by it is certainly top-level.  Surely
someone else
> around here knows offhand whether anywhere else, such as inside node
> definitions, is also top-level.  Or you can test: the fully-qualified
> name of a top-level variable $somevar is $::somevar.
> 
> 
>> To make a long question short: what is the recommended way to override
>> values for certain nodes or groups of nodes (by inheritance)? And
I''d
>> /really/ prefer to do that without having to pass on each and every
value
>> as a parameter to the next included class...
> 
> 
> Things to consider:
> 
> 1) I personally recommend avoiding deep node inheritance hierarchies.
> In fact, I recommend no more than two levels to your node inheritance
> tree.  This may or may not help with your present problem.
We have three levels: a basenode in which we set defaults, a level for
''internal'' and ''external'' servers, since
that is the biggest distinction
in our server park, and every node definition inherits either
''internal''
or ''external''.
> 2) As I mentioned above, you may be able to just change to fully-
> qualified variable names.  That would be quick and relatively
> painless.
Yes. But it doesn''t work ;-)
> 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??

Best regards,
Martijn Grendelman

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

jcbollinger

2011-Aug-01 21:19 UTC

head link

[Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Aaron Grewell

2011-Aug-02 02:20 UTC

head link

Re: [Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices

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.Bollinger@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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Peter Meier

2011-Aug-02 15:18 UTC

head link

Re: [Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices

On 08/02/2011 04:20 AM, Aaron Grewell wrote:> 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.
but then, you should better directly go with hiera.

my2c

~pete

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Martijn Grendelman

2011-Aug-03 12:47 UTC

head link

Re: [Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices

On 02-08-11 17:18, Peter Meier wrote:> On 08/02/2011 04:20 AM, Aaron Grewell wrote:
>> 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.
> 
> but then, you should better directly go with hiera.
I''m currently checking my mileage with Hiera...

Thanks for all your input!

Best regards,
Martijn Grendelman

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Puppet users - Jun 2011 - Puppet 2.7.1, variable scoping, best practices

[Puppet Users] Puppet 2.7.1, variable scoping, best practices

Re: [Puppet Users] Puppet 2.7.1, variable scoping, best practices

[Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices

Re: [Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices

Re: [Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices

[Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices

Re: [Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices

Re: [Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices

Re: [Puppet Users] Re: Puppet 2.7.1, variable scoping, best practices