Hi,
I'm happily aware of the way that there is no concept of unmanaging
something and when this is in the context of a file ownership or whatever,
then that makes sense. But when this is applied to things like nagios
configuration data the principle seems to come unstuck. Or at least, it
seems so to me.
Say I have a nagios_service which uses another template nagios_service. I am
about to rejig my existing configuration to permit some mechanism to
override the default settings, e.g. override the command value from the
default in the template service to some host specific setting, something
(probably syntactially wrong) like...
nagios_service { "diskfree_myhost":
if (defined $diskfree_command) {
command => $diskfree_command
}
use => "diskfree",
}
should work to make this happen.
Now the obvious issue here is that whilst I can add this parameter into the
mix (I intend to do this via puppet dashboard) if I then remove that
variable in the same way I added it, sweet fa will happen, yes? If so then
surely that's of concern? maybe an additional option, another "ensure" value
maybe, to allow existing values to be purged for this kind of data?
Will I have to have a mechanism where I somehow pull a default out of the
air if no specific value is found? I'm a little vague on scoping to be clear
quite how I could set this, but if that's the only way I expect it won't
take too long, but it doesn't feel nice at all, as you wouldn't do that if
you were managing the nagios config file directly in the first place.
Thanks
Chris
--
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.
