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