On Wednesday, October 12, 2016 at 10:10:55 AM UTC-5, Henrik Lindberg wrote: > > 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 > > So, I have 4 networks. one network has the primary-master puppet server, the other 3 have a secondary-master puppet server. Why do you think only one of my secondary-master puppet servers would have this issue most of the time, another secondary-master only some times, and a third secondary-master and the primary-master not at all.
This such that a puppet update on a node from its local secondary-master puppet server experienced the duplicate declaration. But running the puppet update immediately after that but from the primary-master works successfully without error. Would you suppose I have puppet configured differently some how? And if so, what configuration can I look at to try and find the root cause of this issue? Perhaps I can compare some configuration between the working secondary-master and the non-working secondary master? What config might this be? All secondary-master puppet servers are identical, except of course for host name and IP address. > -- > > 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/84ac21a8-282d-4afd-8504-958715395047%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
