On Monday, March 25, 2013 9:14:51 PM UTC-5, Cesar Covarrubias wrote:
>
> I am trying to create a "template" for all my servers. I have 2
> configurations. An NTP client (which is taken care of in the baseclass
> class. I want to create an override specific for the NTP servers by
> declaring something specific in the node declaration. Something like
> "baseclass::ntp:restrict => true,". Or alternatively, how would I change
> one of the already declared variable from baseclass::ntp?
>
> Does anyone have any ideas host to do this?
>
> This is what I have so far:
>
> templates.pp
>
> class baseclass {
> include defaultusers
> include sudoers
> include issue
>
> class { ntp:
> ensure => running,
> servers => ['ntpserver1.host.com',
> 'ntpserver2.host.com',],
> autoupdate => false,
> }
> }
>
>
>
>
> nodes.pp
>
> node default {
> include baseclass
> }
>
> node "ntpserver1.host.com" inherits default {
> <some code here to declare new variable in baseclass::ntp>
> <some code here to change existing variable, such as "ensure">
> }
>
>
I don't have any objection to node inheritance, though I do recommend
keeping node inheritance trees very shallow -- two levels, preferably, or
three as an absolute, special-case maximum. You also need to understand
what it means. Specifically, it really does mean NODE inheritance. The
inheriting node does not get the inherited node's declarations directly,
but rather the whole node, with its own, separate scope. The inherited
node's declarations will be parsed and interpreted independently of any
inheriting nodes that may be in play. Inheriting nodes can only add their
own declarations on top.
There is a syntax for resource parameter override, but it does not work for
classes (and though there are efforts underway to improve that, it *cannot*work
for classes under some circumstances). Your inheriting node therefore
cannot operate as you hoped. The best solution is probably for your class
to draw its data from hiera, so that you can use your hiera hierarchy to
provide different parameters in the first place based on the nature of the
client being configured.
Alternatively, the old-school way to do this is to use class inheritance.
In fact, it is precisely what class inheritance is meant for. The
inheritance approach would involve creating a subclass of ntp, say
ntp::server, which applies appropriate overrides to the parameters of
resources declared by its parent class. You then declare the subclass
(also or instead) to the nodes that should be NTP servers. Consult the
language docs for details.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
