Issue #11921 has been updated by Nick Chappell.
I'm still running into this in Puppet 3.2.1/PuppetDB 1.3.2, on an Ubuntu 13.04
(64-bit) master and agent (the Icinga server). Both are Ruby 1.9.3p194.
Starting with a clean slate, I do a run on the client for it to export its
resource. The first run on my Icinga server correctly creates the host
definition file. It's the second run where it creates the duplicate host
definition in the client1.local.cfg file. From `puppet agent -t --debug` output
on the second run:
<pre>
Info: Applying configuration version '1371534747'
Debug: /Stage[main]//Node[icinga.local]/File[/etc/icinga/objects/hosts]/notify:
subscribes to Service[icinga]
Debug: /Stage[main]//Node[icinga.local]/Nagios_host[client1.local]/notify:
subscribes to File[/etc/icinga/objects/hosts]
Debug: /Schedule[daily]: Skipping device resources because running on a host
Debug: /Schedule[monthly]: Skipping device resources because running on a host
Debug: /Schedule[hourly]: Skipping device resources because running on a host
Debug: Prefetching naginator resources for nagios_host
Notice: /Stage[main]//Node[icinga.local]/Nagios_host[client1.local]/ensure:
created
Debug: Flushing nagios_host provider target
/etc/icinga/objects/hosts/client1.local.cfg
Debug: Finishing transaction 25218700
Info: FileBucket adding {md5}237a0ad811f400b1b44eb2f7b699247f
Debug: /Stage[main]//Node[icinga.local]/Nagios_host[client1.local]: The
container Node[icinga.local] will propagate my refresh event
Debug: Service[icinga](provider=upstart): Could not find icinga.conf in
/etc/init
Debug: Service[icinga](provider=upstart): Could not find icinga.conf in
/etc/init.d
Debug: Service[icinga](provider=upstart): Could not find icinga in /etc/init
Debug: Executing '/etc/init.d/icinga status'
Debug: Node[icinga.local]: The container Class[Main] will propagate my refresh
event
Debug: /Schedule[never]: Skipping device resources because running on a host
Debug: /Schedule[weekly]: Skipping device resources because running on a host
Debug: /Schedule[puppet]: Skipping device resources because running on a host
Debug: Class[Main]: The container Stage[main] will propagate my refresh event
Debug: Finishing transaction 24881100
Debug: Storing state
Debug: Stored state in 0.03 seconds
Notice: Finished catalog run in 0.35 seconds
Debug: Value of 'preferred_serialization_format' (pson) is invalid for report,
using default (yaml)
Debug: report supports formats: b64_zlib_yaml raw yaml; using yaml
</pre>
----------------------------------------
Bug #11921: Puppet not building proper Nagios configs with Exported Resources
https://projects.puppetlabs.com/issues/11921#change-93071
* Author: Mark Frost
* Status: Investigating
* Priority: High
* Assignee:
* Category: nagios
* Target version:
* Affected Puppet version: 2.7.9
* Keywords: puppet nagios exported resources ruby19
* Branch:
----------------------------------------
I'm trying to get Puppet set up to build our nagios configs using Exported
Resources. This seems to be one of the very test cases that Exported Resources
was developed for (it's in the documentation), so I don't feel I've stepped too
far outside of Puppet's intended operation parameters here. Yet, I can't seem
to have any luck at all getting proper configs generated.
I have two issues, and I'm uncertain whether or not they're related. I suspect
they are, but I could very well be wrong. If they are separate, I apologize,
and will be willing to split out a separate ticket.
Here's my setup, which is almost directly ported from the documentation.
In my base class, I have the following:
@@nagios_host { $fqdn:
ensure => present,
alias => $hostname,
address => $ipaddress,
use => "default",
tag => "site${sitecode}",
}
Later, in my nagios server class, I have:
Nagios_host <<| tag == "site${sitecode}" |>> {
target => "/etc/nagios/puppet/dynamic/host.cfg",
notify => Service['nagios'],
require => File['/etc/nagios/puppet/dynamic'],
}
So far, so good.
Now, this is in my testing environment, so right now I have a limited number of
nodes. They are:
xxdnstest01, xxdnstest02, xxdnstest03, lvpuppetdev01, xxis5, xxnagios01.
The only one of note right now is xxnagios01, which is our nagios server.
When I run puppet for the first time, the following host config is generated:
# HEADER: This file was autogenerated at 2012-01-12 11:20:01 -0600
# HEADER: by puppet. While it can still be managed manually, it
# HEADER: is definitely not recommended.
define host {
use default
alias xxdnstest02
address 172.24.29.68
host_name xxdnstest02.lightningsource.com
}
define host {
use default
alias xxdnstest01
address 172.24.29.67
host_name xxdnstest01.lightningsource.com
}
define host {
use default
alias xxdnstest03
address 172.24.29.69
host_name xxdnstest03.lightningsource.com
}
define host {
use default
alias lvpuppetdev01
address 172.24.20.56
host_name lvpuppetdev01.lightningsource.com
}
define host {
use default
alias xxis5
address 172.24.29.66
host_name xxis5.lightningsource.com
}
This is almost right... but for some reason xxnagios01 isn't making an
appearance! This isn't just happening for the host entry itself, but I can't
get any services for xxnagios01 to show up, either.
I don't know if this is specific to naginator, or if it's generally a bug in
Exported Resources. I suspect the latter. It seems like maybe a node can't
import resources that it *itself* exports.
I have verified that the entry does in fact appear in the database:
mysql> select * from resources where restype = "Nagios_host";
+----+-----------------------------------+-------------+---------+----------------+----------+------+---------------------+---------------------+
| id | title | restype | host_id |
source_file_id | exported | line | updated_at | created_at |
+----+-----------------------------------+-------------+---------+----------------+----------+------+---------------------+---------------------+
| 5 | lvpuppetdev01.lightningsource.com | Nagios_host | 3 |
1 | 1 | 64 | 2012-01-12 10:50:12 | 2012-01-12 00:50:13 |
| 9 | xxdnstest01.lightningsource.com | Nagios_host | 5 |
1 | 1 | 64 | 2012-01-12 10:50:17 | 2012-01-12 00:50:19 |
| 13 | xxdnstest02.lightningsource.com | Nagios_host | 7 |
1 | 1 | 64 | 2012-01-12 10:50:21 | 2012-01-12 00:50:30 |
| 17 | xxdnstest03.lightningsource.com | Nagios_host | 9 |
1 | 1 | 64 | 2012-01-12 10:50:33 | 2012-01-12 00:50:40 |
| 1 | xxnagios01.lightningsource.com | Nagios_host | 1 |
1 | 1 | 64 | 2012-01-12 10:39:56 | 2012-01-12 00:45:56 |
| 21 | xxis5.lightningsource.com | Nagios_host | 11 |
1 | 1 | 64 | 2012-01-12 10:50:50 | 2012-01-12 00:51:02 |
+----+-----------------------------------+-------------+---------+----------------+----------+------+---------------------+---------------------+
6 rows in set (0.00 sec)
So I've got 6 resource entries here in the database, but only five are making
it into the file. I'm one short.
So now, it gets really weird.
When I run Puppet *again*, I get the following config file:
# HEADER: This file was autogenerated at 2012-01-12 11:20:01 -0600
# HEADER: by puppet. While it can still be managed manually, it
# HEADER: is definitely not recommended.
define host {
use default
alias xxdnstest02
address 172.24.29.68
host_name xxdnstest02.lightningsource.com
}
define host {
use default
alias xxdnstest01
address 172.24.29.67
host_name xxdnstest01.lightningsource.com
}
define host {
use default
alias xxdnstest03
address 172.24.29.69
host_name xxdnstest03.lightningsource.com
}
define host {
use default
alias lvpuppetdev01
address 172.24.20.56
host_name lvpuppetdev01.lightningsource.com
}
define host {
use default
alias xxis5
address 172.24.29.66
host_name xxis5.lightningsource.com
}
define host {
use default
alias xxdnstest02
address 172.24.29.68
host_name xxdnstest02.lightningsource.com
}
Notice that the first entry of the file, xxdnstest02, has now been duplicated
to the bottom of the file inexplicably. No matter what I do, Puppet wants to
enforce this. I did some tracing back through Puppet's internals, and inserted
some debug statements, and it appears that Puppet is *parsing* the file
correctly. My first suspicion was that the comments at the top were causing it
to be unable to see the first entry, but that's not the case. It's in the
@records variable correctly before it tries to insert the new node.
This is the issue that I suspect is related, but may not be. My current
suspicion is that Puppet is somehow "noticing" that xxnagios01 is absent, and
so it then attempts to add xxnagios01 to the file. However, due to whatever the
first bug is, it fails to do so, and somehow just winds up copying the first
node.
However... on the third run, the config file is unchanged. This is somewhat
surprising to me. If Puppet *was* trying to add xxnagios01, and failed, I would
expect it to add it again every time, and for the first entry to be reproduced
on each subsequent run. As it is, Puppet seems to be happy once the first entry
and the last entry are the same, and then it stops trying to add more.
This leaves me with a couple of fairly major problems.
1. I cannot get resources exported from my nagios server to show up in my
nagios configs
2. Puppet is ultimately generating *broken* configs. Nagios will not start up
when there are duplicate definitions like this, so overall... the feature is
failing me. =/
I'm running Puppet 2.7.9, with Ruby 1.9.2p290. If I can provide any additional
information, please don't hesitate to ask.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" 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-bugs.
For more options, visit https://groups.google.com/groups/opt_out.
