Issue #11921 has been updated by Kelsey Hightower.
Mark, Thanks for reporting this issue, I have never used the nagios type, so I don't have any good suggestions on this one. Can any provide any insight on this? ---------------------------------------- Bug #11921: Puppet not building proper Nagios configs with Exported Resources https://projects.puppetlabs.com/issues/11921 Author: Mark Frost Status: Unreviewed Priority: Normal Assignee: Category: nagios Target version: Affected Puppet version: 2.7.9 Keywords: puppet nagios exported resources 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 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-bugs?hl=en.
