On Dec 16, 2008, at 4:12 PM, Eric Gerlach wrote:
>>
>> You can use Stored Configs, which will store Puppet Types in a MySQL
>> database,
>
> To narrow my question, then: What syntax would one use to access
> facts from
> Node A in a template being instantiated by Node B? (Assuming one
> has stored
> configs enabled)
You'll have to get that from someone else - ordinarily, you will
export entire resources from one node to another, not individual
attributes, as I understand it. (But I do not use stored configs) So
something like:
class nagios-target {
@@nagios_host { $fqdn:
ensure => present,
alias => $hostname,
address => $ipaddress,
use => "generic-host",
}
@@nagios_service { "check_ping_${hostname}":
check_command => "check_ping!100.0,20%!500.0,60%",
use => "generic-service",
host_name => "$fqdn",
notification_period => "24x7",
service_description => "${hostname}_check_ping"
}
}
class nagios-monitor {
package { [ nagios, nagios-plugins ]: ensure => installed, }
service { nagios:
ensure => running,
enable => true,
#subscribe => File[$nagios_cfgdir],
require => Package[nagios],
}
# collect resources and populate /etc/nagios/nagios_*.cfg
Nagios_host <<||>>
Nagios_service <<||>>
}
(Taken directly from ExportedResources on the wiki)
It's not like you can use the facts in a template directly.
>> or you can use iClassify, which will work as an external
>> node tool that tracks attributes in a database and indexes them in
>> Solr. (you can then query the full text search interface from your
>> templates.)
>
> iClassify looks quite neat, but I'm not sure that it's what I'm
> really looking
> for in this case. I might add it to my mix later, though.
Yep - the only reason you would care is if you can't access facts from
Node A in a template on Node B via stored configs, whcih I don't
believe you can at this stage. If you query them via iClassify, you
could.
> I'm not so much interested in the performance difference, but if I'm
> installing
> a bunch of new packages in Debian, I would want them to install
> together to
> avoid pulling incorrect dependencies. If they install one at a
> time, one
> package might pull in a package I don't want (to satisfy a
> dependency I'm
> intending to satisfy with another package).
>
> It's not a big deal, as I've had to solve that problem already (just
> create
> meta-packages that depend on the real packages you want to install),
> but
> prefetch and flush would be a better way to do it.
Gotcha - yeah, puppet has no way to handle this right now.
Adam
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
