On Thu, Oct 3, 2013 at 9:48 AM, David Thompson
<dthomp...@waisman.wisc.edu>wrote:

> On 10/3/13 9:07 AM, jcbollinger wrote:
>
>  And you're certain that $nagios_server evaluates to true on the machines
>> that nevertheless fail to get the expected Nagios_host resources
>> applied?  You could probe that by changing the above to
>>
> >
>
>> if $nagios_server {
>>    Nagios_host <<| |>>
>>    notify { 'I am a nagios server': }
>> } else {
>>    notify { 'I am not a nagios server': }
>> }
>>
>> That will also help you catch the case that the class containing the
>> above is not included in the catalog at all, for then you would see
>> neither the Notify message in the agent log.  You can also watch your
>> query log for the query by which Puppet retrieves all the wanted
>> Nagios_host resources; if nothing else is fruitful then the details of
>> the query might reveal some useful information.
>>
>
> First to answer.  I have one computer that runs nagios.  That's the (only)
> computer that has $nagios_server defined.  The computers that I want to
> monitor have the @@nagios_host {} resource.  I've verified this up and down.
>
> I've done some more testing, and there's something very funny going on.
>  In my manifests, I have the following:
>
>
>       notify {"Nagios Base: $fqdn $hostname $ipaddress": }
>       @@nagios_host { $fqdn:
>         ensure => present,
>         alias => $hostname,
>         address => $ipaddress,
>         use => "linux-server",
>       }
>
> On the hosts to be monitored, I see the notify, and, as I've said, I see
> the db inserts, but then nothing comes up in the REST query.  HOWEVER, if I
> take the lines above and put them in a separate .pp file and "puppet apply"
> that file, then I see the resources via the REST query. My understanding
> was that once a resource gets defined, that's the end of the story, but
> it's clearly not what's happening here.
>
> So, "puppet agent --test --environment production" fails to create
> resources findable via REST (and in fact removes them if they're present),
> but "puppet apply foo.pp" (with foo.pp containing the statements above)
> makes them findable (and they show up in nagios_hosts.cfg on the nagios
> server).


PuppetDB will only return resources for nodes which it haven't been marked
inactive...is it possible that's happened for some of your nodes? Hitting
http://localhost:8080/v2/nodes on your puppetdb server should dump out
everything puppetdb knows about your hosts, including when they were
deactivated (or null if they've not been deactivated).


>
>
>  though I don't expect using that form will change anything.  I'm more
>> interested, though, in the back end.  That is, is puppetdb for some
>> reason failing to serve up resources that are in fact recorded in the
>> back-end DB, or are the resources either not making it to the DB in the
>> first place, or are they being purged from the DB between being entered
>> and being queried?
>>
>
> That's a very good question.  I can certainly find catalog_resource and
> resource_params records that *look* like they contain appropriate
> Nagios_host resources, but the REST API says no, and if I run the actual
> sql query out of the postgres statement log, it says no.  The sql query
> itself is a complex enough to be beyond my db-mojo to understand why it's
> not finding any Nagios_host resources.
>
>
>  You said earlier that some nagios hosts are getting configured, at least
>> on some machines, but I didn't completely understand which hosts are
>> getting configured on which machines.  Are there machines that get all
>> the expected hosts?  Are there nagios_hosts that get configured on all
>> machines?  More generally, what is the nature of the correlation (that
>> you have recognized) between declared nagios host resources and the
>> machines on which puppet manages those resources?
>>
>
> Yes, sometimes I've gotten some partial Nagios_host data generated on the
> nagios server, but never in any discernible or repeatable form.
>
> It looks like enlightenment lies in understanding the difference between
> the puppet agent and puppet apply runs.
>
>
> --
> David Thompson
> Waisman Center Brain Imaging and Behavior Lab
> 1500 Highland Ave. Room T133
> Madison, WI  53705-2280
> (608) 265-6608
> dthompson (at) waisman (dot) wisc (dot) edu
>
> --
> 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 
> puppet-users+unsubscribe@**googlegroups.com<puppet-users%2bunsubscr...@googlegroups.com>
> .
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at 
> http://groups.google.com/**group/puppet-users<http://groups.google.com/group/puppet-users>
> .
> For more options, visit 
> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> .
>

-- 
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 puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to