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, [email protected] 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]).
The size of both catalog files are exactly the same (I am referring to this file: /var/lib/puppet/client_data/catalog/server1.mydomain.example.com.json ). The only difference inside the file is the order of items in the json arrays. I have checked carefully, the order in which Rsyslog classes definitions are appearing in '.data.edges[]' and '.data.resources[]' is in the same order of appearance between catalogs from both servers, however they are intermingled with definitions from other modules differently - with this I mean the definition for Class[Rsyslog::Config] appears as element .data.edges[23].target in the primary master (that is successful), but as element .data.edges[4].target in the secondary master (that fails with duplicate declaration), though no other Rsyslog class comes before this one in each catalog. So the only difference I can see between the two puppet servers is the order of the overall elements in the catalogs' json hashes and arrays. Could this be a cause of the duplicate declaration error? And if it might be, how do I get the definitions in the catalog to compile into the correct order that would prevent the duplicate declaration error? -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/385f8838-9518-4d1f-87a2-6e777e5c3d31%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
