On 11/16/11 3:54 PM, jcbollinger wrote:
On Nov 16, 3:59 am, flex<frostyn...@gmail.com> wrote:
I read the guide
athttp://docs.puppetlabs.com/guides/scope_and_puppet.htmlandothers'
mail, i am a little confused now, below is my understanding:
1. top scope only refers to site.pp, not include node definitions and facts.
Top scope refers to anything outside all class and node definitions.
Top scope variables can appear in any manifest file, but site.pp is a
very good choice because it is always processed, and first. Top scope
variables in most other locations may sometimes fail to be visible in
manifests other than the ones where they appear.
If you put a class or node definition in site.pp, that class's or
node's variables are not in top scope.
Facts certainly are in top scope; in some manifest sets they are the
*only* variables in top scope.
2. in puppet class, using variables not local, must specify the namespace,
like $class::variable,
if it's a top scope variable or a fact variable or a variable in node
definition, using $::variable.
For Puppet 2.7.x and below, this is not always the case: you can
access variables in the current dynamic scope by their simple names.
Top scope variables are always in the current dynamic scope, but a
narrower scope might define a variable having the same simple name, so
it is always safest to use $::variable when that's what you mean.
Dynamic scope can apply to class variables, too, but again it's safest
to use refer to non-local variables by their fully-qualified names.
Starting in Puppet 2.8, however, it will be mandatory to refer to non-
local variables by their fully-qualified names. In preparation for
that, Puppet 2.7.x emits warning when your manifests resolve non-local
variables from the dynamic scope.
3. in template erb files, always using scope.lookupvar("class::variable")
to get the value, even if the erb and the variable used in the same module
or it is a fact variable
The docs suggest that templates can use all the simple variable names
that can be resolved in the scope where they are invoked, but I cannot
independently confirm that. Certainly, wherever you need or want to
use a qualified name, scope.lookupvar() is your tool.
are these points correct?
btw, only some of my old code give dynamic lookup warnings under puppet
2.7, does this mean the others not need to modify?
I doubt it would be safe to say that manifests that do not elicit
dynamic lookup warnings will not need any modification to work with
Puppet 2.8. Also, do understand that it is not necessarily the case
that every manifest is processed for every client, so you have to take
care in judging which code gives warnings and which doesn't.
If you use Geppetto you will get validation of all variable references
in any .pp file irrespective if it gets evaluated or not. Geppetto is
using the rules that John described above.
The rules as far as I have understood them wrt. unqualified variables
are that they may reference:
* a locally scoped variable
* a top level scoped variable
* a (local) class or definition parameter
* an inherited class parameter (somewhat unclear on the rules here)
* (before 2.8 a dynamically scoped variable, warning in 2.7)
* a meta variable ($name, $title, $module_name, $0-$n)
* an assigned meta parameter (in definitions)
Regards
- henrik
--
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.
