On 12/10/16 14:59, jcbollinger wrote:
On Tuesday, October 11, 2016 at 3:54:25 PM UTC-5, re-g...@wiu.edu wrote:
On Monday, October 10, 2016 at 9:07:35 AM UTC-5, jcbollinger wrote:
On Friday, October 7, 2016 at 10:39:58 AM UTC-5, re-g...@wiu.edu
wrote:
Well... The node I have been testing the duplicate
declaration on uses a puppet secondary-master server, as it
is on a remote network segment. It does not connect directly
to the puppet primary-master in which The Forman is running on.
So I did some work to get this particular "server1" node to
use the puppet primary-master that The Foreman is running
on. When I run a puppet update, it completes without error.
When I switch back to the puppet secondary-master, I get the
duplicate class error.
They are both running puppet 3.8.7-1 on CentOS 6.
The YAML produced by both is exactly 100% the same. So I can
assume the YAML structure is not the issue.
Would this suggest that the puppet secondary-master server
is the issue, or the client connecting to it is perhaps not
always getting what it wants from the slave?
Remember that the puppet updates will complete correctly for
many hours, then magically change to this error. And
vice-versa, be in error for many hours, and then magically
change to completing correctly. Also that sometime changing
configuration in The Forman can trigger the Error to occur
AND other times trigger to Error to stop occurring.
Also note, I only have this problem with the saz-rsyslog
module - NEVER with any other puppet module.
When I remove the saz-rsyslog module, all issues disappear.
I am not prepared to believe that identical implementations of
Puppet's catalog builder running on substantially identical
platforms with identical inputs behave differently. Since you
do see variations in behavior, therefore, I conclude that those
differences can be attributed to differences in implementation,
platform, or (most likely) inputs.
I have made sure the puppet modules are 100% in sync between
primary and secondary master server.
And I have restarted the puppet processes on the
secondary-master server, but the error will continue on the
nodes.
Those are good steps. To really troubleshoot this thoroughly,
however, I think you'll need to be systematic: capture the ENC
output for each catalog request for a given node (or for all
nodes), with timestamps and associated success / failure of
catalog compilation. Compare the ENC output for successful
catalog builds with that for failed builds and look for systematics.
Either at the same time or separately, you should look into
whether Puppet's environment cache has an impact here. Some of
the behaviors you describe make me rather suspicious of this.
Supposing that you are using directory environments, you should
experiment both with disabling caching altogether (set the
environment_timeout configuration option to 0 (its default)) and
with caching indefinitely (set environment_timeout to
"unlimited"). Note that Puppet recommends against using any
other setting for that option. You could also try turning on
the ignorecache option at the master.
John
So I ran a `puppet agent -t` on one of the problem nodes against the
primary master puppet server (which was successful), and then
afterwards the secondary master puppet server (which produces the
duplicate declaration error for Class[Rsyslog]).
Just a thought. If it first works and then stops working it could be
that the logic realizes exported resources and that it clashes with a
resource already created/realized.
- henrik
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/ae4de2f3-3898-b662-cb03-1ca5fdb73040%40puppet.com.
For more options, visit https://groups.google.com/d/optout.
