Issue #11921 has been updated by Mark Frost.
I've verified that the first part of this bug, at least, is a bug in Exported
Resources.
For example, I've set up a simple Exported Resources test case with Cron:
In Base class:
@@cron { "ping ${fqdn}":
user => root,
hour => 3,
command => "nslookup ${fqdn}",
tag => "site${sitecode}",
}
In server class (for one node only):
Cron <<| tag == "site${sitecode}" |>>
Database entries:
mysql> select * from resources where restype = "Cron";
+----+----------------------------------------+---------+---------+----------------+----------+------+---------------------+---------------------+
| id | title | restype | host_id |
source_file_id | exported | line | updated_at | created_at |
+----+----------------------------------------+---------+---------+----------------+----------+------+---------------------+---------------------+
| 29 | ping lvpuppetdev01.lightningsource.com | Cron | 3 |
1 | 1 | 71 | 2012-01-12 12:09:08 | 2012-01-12 12:09:08 |
| 31 | ping xxdnstest01.lightningsource.com | Cron | 5 |
1 | 1 | 71 | 2012-01-12 12:10:18 | 2012-01-12 12:10:18 |
| 35 | ping xxdnstest02.lightningsource.com | Cron | 7 |
1 | 1 | 71 | 2012-01-12 12:10:36 | 2012-01-12 12:10:36 |
| 33 | ping xxdnstest03.lightningsource.com | Cron | 9 |
1 | 1 | 71 | 2012-01-12 12:10:30 | 2012-01-12 12:10:30 |
| 25 | ping xxnagios01.lightningsource.com | Cron | 1 |
1 | 1 | 71 | 2012-01-12 12:07:32 | 2012-01-12 12:07:32 |
| 27 | ping xxis5.lightningsource.com | Cron | 11 |
1 | 1 | 71 | 2012-01-12 12:08:54 | 2012-01-12 12:08:54 |
+----+----------------------------------------+---------+---------+----------------+----------+------+---------------------+---------------------+
6 rows in set (0.00 sec)
Resulting crontab:
# HEADER: This file was autogenerated at 2012-01-12 12:20:30 -0600 by
puppet.
# HEADER: While it can still be managed manually, it is definitely not
recommended.
# HEADER: Note particularly that the comments starting with 'Puppet Name'
should
# HEADER: not be deleted, as doing so could cause duplicate cron jobs.
# Puppet Name: ping lvpuppetdev01.lightningsource.com
50 3 * * * nslookup lvpuppetdev01.lightningsource.com
# Puppet Name: ping xxdnstest02.lightningsource.com
50 3 * * * nslookup xxdnstest02.lightningsource.com
# Puppet Name: ping xxis5.lightningsource.com
50 3 * * * nslookup xxis5.lightningsource.com
# Puppet Name: ping xxdnstest01.lightningsource.com
50 3 * * * nslookup xxdnstest01.lightningsource.com
# Puppet Name: ping xxdnstest03.lightningsource.com
50 3 * * * nslookup xxdnstest03.lightningsource.com
Notice there's no crontab entry for xxnagios01, even though it appears in the
database properly.
The second issue, with the phantom duplicate final-entry, still seems to be
nagios-specific. I haven't been able to reproduce it with crons as an Exported
Resource.
Should I split this off into a separate Exported Resources ticket?
----------------------------------------
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.
