> Wow, how did I miss that? That may very well solve a bunch of my
> problems- it's not as transparent as I would prefer (you can't see at
> a glance what resources a node references) but it has got to be better
> than what I'm dealing with now. Thanks for the feedback.
Nope spoke too soon. Scoping screws this up.
For example:
class zones::global {
$ntp_servers = ['ntp01.example.com',
'ntp02.example.com']
$ntp_acls = ['']
include ntp
}
class zones::nyc {
$ntp_servers = ['ntp01.othersite.com',
'ntp02.othersite.com']
include zones::global
}
node host1.example.com {
include zones::nylrc
}
The variables in global are available to NYC but the variables I have
overridden in NYC are not available to global. In the end,
host1.example.com ends up with ntp01.example.com as it's NTP server
instead of ntp01.othersite.com because of scoping.
Am I crazy for thinking this sort of hierarchical structure would be
amazingly useful and is basically impossible with puppet?
Is there some reason I am missing that would make the above a terrible
idea?
Without the above sort of hierarchy I'm going to end up with a jumble
of logic statements and node descriptions that could otherwise be made
incredibly simple.
What am I missing?
-Don
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
