On Wednesday, September 5, 2012 1:19:16 PM UTC-5, Jakov Sosic wrote:
>
> Hi.
>
> I've seen in many modules at puppet-forge this kind of organization:
>
> class myclass(
> $somevar='value'
> ) inherits myclass::params {
> file { $mydir:
> ensure => directory,
> }
> }
>
> class myclass::params {
> $mydir = '/some/path'
> }
>
>
> Now, I wonder how can I override $mydir from node definition?
Not as your example is written, read on.
> Or am I
> missing the whole point, am I supposed to put $mydir inside standard
> brackets and then call the class with something like:
>
> node mynode.mydomain.com {
> class myclass($mydir='/some/other/path')
> }
>
>
I think very likely have overlooked a key aspect of the pattern you
observed (or else the modules you are looking at aren't good teaching
examples). The usual usage of the pattern I suspect you've seen is more
like this:
# This might as readily be named mymodule::myclass
class mymodule ($myparam = $myparam_default) inherits mymodule::params {
file { $myparam:
# ...
}
}
class mymodule::params {
$myparam_default = '/some/path'
}
The key difference there is that a variable declared by the ::params class
is used as a default value for a parameter of the class that inherits it.
That's the *only* reason why class inheritance is reasonable in this
particular case. As a matter of good style, classes inherited for this
purpose should normally contain only variable declarations.
If one class wants to use another class's variables, but not as class
parameter defaults, then it should not inherit from that class. Instead,
it should 'include' that class (provided it is not parametrized) and then
refer to the variables by their fully-qualified names, such as
$mymodule::params::anothervar. Inheriting the ::params class is simply a
trick to ensure the variables are initialized and accessible for use before
any part of the class body of the inheriting class is parsed (i.e. in time
to be used as parameter defaults).
Getting back to your questions, no, you cannot override the value of a
class variable, but you *can* provide your own values for class parameters,
which will then be used instead of whatever default values may have been
declared. That's done like so:
class { "mymodule":
# parameters follow...
myparam => 'custom value'
}
Yes, it looks very much like a resource declaration. No, I don't think
that was a good design decision, but the prevailing opinion at PuppetLabs
is different, or was when parametrized classes were added.
Before you start swooning over how nice parametrized classes look, let me
warn you that they carry some substantial drawbacks. Therefore, I urge you
to avoid using them in your own code as much as you can do, at least until
you understand Puppet well enough to appreciate why they might make sense
in some circumstances (clue me in when you figure that out), and especially
until you appreciate the problems they present. Hint: the biggest one is
that parametrized classes cannot be declared more than once.
There are other, better ways to get data to your classes, notably data
access functions such as hiera(), and global or [other]class variables.
Puppet 3 does shine up parametrized classes a lot, in large part by
integrating hiera directly into parameter value resolution. Nevertheless,
you don't need class parameters, and even in Puppet 3, parametrized classes
retain a few pointy bits. Therefore, I'd focus on building classes that
rely on hiera (which for Puppet 2.x is a third-party extension) where they
need external data, as that will serve you well both now and going forward.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/sHqw7Z31O_sJ.
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.
