Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[jcbollinger]

On Friday, October 21, 2016 at 9:48:02 AM UTC-5, re-g...@wiu.edu wrote:
 

> As it seems saz-rsyslog is the best puppet module for managing rsyslog, I 
> decided to take a hint from @jcbollinger on configuration, rather than 
> replacing the module.
>
> I decided to change the values of the parent Rsyslog class parameters so 
> that they are the seen as the "default" for The Foreman (I refer to 
> "default" as eluded to in a previous reply regarding use of Hiera to change 
> these values). But I did not want to implement Hiera just for one class and 
> four parameters. So I added the following changes on all puppet master 
> servers to the production/manifests/site.pp file:
>
> File: /etc/puppet/environments/production/manifests/site.pp
> class { 'rsyslog':
> preserve_fqdn=> true,
> gnutls_package_name  => false,
> relp_package_name=> false,
> rsyslog_package_name => false
> }
>
> This changes the values of these parameters globally, which is how I had 
> it set in The Foreman any way.
> And in The Foreman, I removed all values set for the parent Rsyslog class 
> parameters, leaving them checked to use the default value. I left the 
> values set in The Foreman for Rsyslog::client subclass parameters unchanged 
> (which is necessary because these values change based on node facts). I did 
> leave the rsyslog parent class assigned to all nodes in The Foreman, though 
> the ENC output does not set any parameters for this class.
>
> This fixed the duplicate declaration issue I was experiencing.
> The reason why I believe this fixed the duplicate declaration error is 
> because I assume Puppet's intended behavior is to always declare in the 
> catalog the classes from the site.pp file before the classes from the ENC.
>
> This is obviously not ideal, but I justify this with the argument that I 
> am simply changing the "default" values of the saz-rsyslog puppet module 
> Rsyslog class - but without having to modify the module's code.
> This is a good enough work-around for me for now.
> -RG
>
>

I'm glad you have found a workaround that solves the problem for you.  I 
suspect that you are basically correct about why it works; that is, that 
Puppet evaluates the top-scope declaration of class ::rsyslog before it 
evaluates any class declarations from the ENC.

To make future trouble in this area less likely, however, I recommend that 
you adjust your mental model.  Unlike my recommended solution based on 
automated data binding, what you have done is *not* analogous to changing 
Foreman's view of the default values for the class's parameters.

   - In the first place, your class declaration in site.pp is indeed a *bona 
   fide* class declaration, applying to every node.  As long as it's there, 
   every node will get class `rsyslog`, with the parameters you've specified, 
   regardless of what you specify via The Foreman.
   - In the second place, you now will *reliably* get duplicate declaration 
   errors if you try to declare any non-default parameters for class rsyslog 
   via Foreman.  That may actually be an improvement over getting such errors 
   unpredictably, however.

Note also that your solution does not resolve the underlying problem of 
your set of declarations being sensitive to evaluation order.  Instead, it 
asserts sufficient control over the evaluation order to avoid the errors 
you experienced.  I find no documentation of the relative evaluation order 
you observe, and if it is undocumented then it is fair game for a change in 
some future version of Puppet.  (And indeed, Puppet has historically been 
pretty open to changing even documented behavior, albeit in a manner 
consistent with its commitment to semantic versioning.


John

-- 
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/47396af8-65ff-4051-86e0-88e3a363620a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

On Thursday, October 20, 2016 at 4:42:47 PM UTC-5, re-g...@wiu.edu wrote:
>
>
>
> On Thursday, October 20, 2016 at 10:31:59 AM UTC-5, jcbollinger wrote:
>>
>>
>>
>> On Wednesday, October 19, 2016 at 4:51:20 PM UTC-5, re-g...@wiu.edu 
>> wrote:
>>>
>>>
>>>
>>> On Tuesday, October 18, 2016 at 9:49:23 AM UTC-5, jcbollinger wrote:



 On Monday, October 17, 2016 at 3:15:51 PM UTC-5, re-g...@wiu.edu wrote:
>
>
>
> On Friday, October 14, 2016 at 5:08:31 PM UTC-5, re-g...@wiu.edu 
> wrote:
>>
>>
>>
>> On Thursday, October 13, 2016 at 9:15:58 AM UTC-5, Rob Nelson wrote:
>>>
>>> I've worked with saz in the past and believe he would be very 
>>> receptive to PRs that address this issue, as well, if RG or anyone else 
>>> wanted to contribute them. That would be one of the better solutions to 
>>> the 
>>> problem.
>>>
>>> Rob Nelson
>>> rnel...@gmail.com
>>>
>>>
>>> I think I've given you a pretty good handle on the nature of the 
 problem, and I'm inclined to think that a solution that addresses the 
 problem at its root will take care of the whole suite of issues.

>>>
>> Lots and lots of thanks to jcbollinger.
>> Here is what I have done as a result of this thread:
>>
>> Submitted an issue with saz-rsyslog:
>> Duplicate Declaration Class[Rsyslog] with The Foreman as ENC during 
>> catalog compilation #237
>> https://github.com/saz/puppet-rsyslog/issues/237
>>
>> Posted a follow-up question to a related thread on The Foreman mail 
>> list to determine if The Foreman also may be exhibiting a bug, or if the 
>> issue may be my configuration:
>> Duplicate declaration error.
>> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion 
>>   (my post is waiting for approval as of 22:00 GMT 10/14/2016)
>>
>> My current thought at this time is two points:
>> 1. saz-rsyslog is written in such a way that declaring a subclass 
>> before the parent class causes duplicate declaration errors - but I am 
>> told 
>> the module inheritance should be addressed, and would resolve this issue.
>> 2. The Foreman, under undetermined circumstances (maybe my 
>> misconfiguration), will randomly declare parent classes and subclass out 
>> of 
>> order - but I am told this is not an issue with puppet modules that use 
>> inheritance correctly - thus there might be an underlying bug with The 
>> Foreman because this error will not appear under modules' expected 
>> inheritance.
>>
>>
> This is what was posted on The Foreman mail list group:
> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion
>
>> This is an issue with the format of the ENC YAML used between Foreman 
>> and Puppet, and is best fixed in the module. 
>> The list of classes is given as a hash/dictionary and so has no 
>> particular order defined - it's down to the Puppet master/server to 
>> iterate over it, and it probably does so in no particular order. It 
>> isn't under Foreman's control.
>
>
> I now believe this is truly the root of my problem. 
>
> The evidence is looking at the ENC output and the Puppet-generated 
> Catalog file on each of the master puppet servers.
> As you can see below, the puppet-generated catalog on the 
> secondary-master puppet server has put rsyslog::client before rsyslog - 
> this causes the failure.
> However, The Foreman ENC output is the same on both primary and 
> secondary master puppet servers.
>
>

 You have taken a step backward there.  I remind you that duplicate 
 declaration errors occur *during catalog building*, and that catalog 
 building fails if one occurs.  It is therefore impossible to compare a 
 catalog from the failure case to a catalog from the success case, because 
 no catalog is ever created in the failure case.


>>> Then I was mistaken in thinking that the node file 
>>> (/var/lib/puppet/yaml/node/server1.mydomain.example.com.yaml) was the data 
>>> (catalog pre-data) written to a file before the catalog compilation 
>>> procedure.
>>>
>>
>>
>> But you said you were looking at the *catalog* not "catalog pre-data". 
>> I'm sure you appreciate the tremendous difference between those.
>>
>>  
>>
>>> I assumed this because both the foreman and node files are created new 
>>> every time server1 performs a puppet agent update, even when the result is 
>>> a 400 error for the catalog compilation.
>>> If I am mistaken in this, then I need someone to tell me how to get the 
>>> data of the catalog that is failing to be compiled, so that I can compare 
>>> it with other sources.
>>>
>>> Here is the procedure I have been assuming (I am not an expert on puppet 
>>> internals):
>>> 1. (server1)puppet-agent -> puppet-master
>>> 2. puppet-m

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

On Thursday, October 20, 2016 at 10:31:59 AM UTC-5, jcbollinger wrote:
>
>
>
> On Wednesday, October 19, 2016 at 4:51:20 PM UTC-5, re-g...@wiu.edu wrote:
>>
>>
>>
>> On Tuesday, October 18, 2016 at 9:49:23 AM UTC-5, jcbollinger wrote:
>>>
>>>
>>>
>>> On Monday, October 17, 2016 at 3:15:51 PM UTC-5, re-g...@wiu.edu wrote:



 On Friday, October 14, 2016 at 5:08:31 PM UTC-5, re-g...@wiu.edu wrote:
>
>
>
> On Thursday, October 13, 2016 at 9:15:58 AM UTC-5, Rob Nelson wrote:
>>
>> I've worked with saz in the past and believe he would be very 
>> receptive to PRs that address this issue, as well, if RG or anyone else 
>> wanted to contribute them. That would be one of the better solutions to 
>> the 
>> problem.
>>
>> Rob Nelson
>> rnel...@gmail.com
>>
>>
>> I think I've given you a pretty good handle on the nature of the 
>>> problem, and I'm inclined to think that a solution that addresses the 
>>> problem at its root will take care of the whole suite of issues.
>>>
>>
> Lots and lots of thanks to jcbollinger.
> Here is what I have done as a result of this thread:
>
> Submitted an issue with saz-rsyslog:
> Duplicate Declaration Class[Rsyslog] with The Foreman as ENC during 
> catalog compilation #237
> https://github.com/saz/puppet-rsyslog/issues/237
>
> Posted a follow-up question to a related thread on The Foreman mail 
> list to determine if The Foreman also may be exhibiting a bug, or if the 
> issue may be my configuration:
> Duplicate declaration error.
> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion 
>   (my post is waiting for approval as of 22:00 GMT 10/14/2016)
>
> My current thought at this time is two points:
> 1. saz-rsyslog is written in such a way that declaring a subclass 
> before the parent class causes duplicate declaration errors - but I am 
> told 
> the module inheritance should be addressed, and would resolve this issue.
> 2. The Foreman, under undetermined circumstances (maybe my 
> misconfiguration), will randomly declare parent classes and subclass out 
> of 
> order - but I am told this is not an issue with puppet modules that use 
> inheritance correctly - thus there might be an underlying bug with The 
> Foreman because this error will not appear under modules' expected 
> inheritance.
>
>
 This is what was posted on The Foreman mail list group:
 https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion

> This is an issue with the format of the ENC YAML used between Foreman 
> and Puppet, and is best fixed in the module. 
> The list of classes is given as a hash/dictionary and so has no 
> particular order defined - it's down to the Puppet master/server to 
> iterate over it, and it probably does so in no particular order. It 
> isn't under Foreman's control.


 I now believe this is truly the root of my problem. 

 The evidence is looking at the ENC output and the Puppet-generated 
 Catalog file on each of the master puppet servers.
 As you can see below, the puppet-generated catalog on the 
 secondary-master puppet server has put rsyslog::client before rsyslog - 
 this causes the failure.
 However, The Foreman ENC output is the same on both primary and 
 secondary master puppet servers.


>>>
>>> You have taken a step backward there.  I remind you that duplicate 
>>> declaration errors occur *during catalog building*, and that catalog 
>>> building fails if one occurs.  It is therefore impossible to compare a 
>>> catalog from the failure case to a catalog from the success case, because 
>>> no catalog is ever created in the failure case.
>>>
>>>
>> Then I was mistaken in thinking that the node file 
>> (/var/lib/puppet/yaml/node/server1.mydomain.example.com.yaml) was the data 
>> (catalog pre-data) written to a file before the catalog compilation 
>> procedure.
>>
>
>
> But you said you were looking at the *catalog* not "catalog pre-data". 
> I'm sure you appreciate the tremendous difference between those.
>
>  
>
>> I assumed this because both the foreman and node files are created new 
>> every time server1 performs a puppet agent update, even when the result is 
>> a 400 error for the catalog compilation.
>> If I am mistaken in this, then I need someone to tell me how to get the 
>> data of the catalog that is failing to be compiled, so that I can compare 
>> it with other sources.
>>
>> Here is the procedure I have been assuming (I am not an expert on puppet 
>> internals):
>> 1. (server1)puppet-agent -> puppet-master
>> 2. puppet-master -> (exec)puppet[external_nodes] 
>> server1.mydomain.example.com -> foreman ENC
>> 3. foreman ENC -> 
>> /var/lib/puppet/yaml/foreman/server1.mydomain.example.com.yaml -> 
>> puppet-master
>> 4. puppet-mas

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[jcbollinger]

On Wednesday, October 19, 2016 at 4:51:20 PM UTC-5, re-g...@wiu.edu wrote:
>
>
>
> On Tuesday, October 18, 2016 at 9:49:23 AM UTC-5, jcbollinger wrote:
>>
>>
>>
>> On Monday, October 17, 2016 at 3:15:51 PM UTC-5, re-g...@wiu.edu wrote:
>>>
>>>
>>>
>>> On Friday, October 14, 2016 at 5:08:31 PM UTC-5, re-g...@wiu.edu wrote:



 On Thursday, October 13, 2016 at 9:15:58 AM UTC-5, Rob Nelson wrote:
>
> I've worked with saz in the past and believe he would be very 
> receptive to PRs that address this issue, as well, if RG or anyone else 
> wanted to contribute them. That would be one of the better solutions to 
> the 
> problem.
>
> Rob Nelson
> rnel...@gmail.com
>
>
> I think I've given you a pretty good handle on the nature of the 
>> problem, and I'm inclined to think that a solution that addresses the 
>> problem at its root will take care of the whole suite of issues.
>>
>
 Lots and lots of thanks to jcbollinger.
 Here is what I have done as a result of this thread:

 Submitted an issue with saz-rsyslog:
 Duplicate Declaration Class[Rsyslog] with The Foreman as ENC during 
 catalog compilation #237
 https://github.com/saz/puppet-rsyslog/issues/237

 Posted a follow-up question to a related thread on The Foreman mail 
 list to determine if The Foreman also may be exhibiting a bug, or if the 
 issue may be my configuration:
 Duplicate declaration error.
 https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion 
   (my post is waiting for approval as of 22:00 GMT 10/14/2016)

 My current thought at this time is two points:
 1. saz-rsyslog is written in such a way that declaring a subclass 
 before the parent class causes duplicate declaration errors - but I am 
 told 
 the module inheritance should be addressed, and would resolve this issue.
 2. The Foreman, under undetermined circumstances (maybe my 
 misconfiguration), will randomly declare parent classes and subclass out 
 of 
 order - but I am told this is not an issue with puppet modules that use 
 inheritance correctly - thus there might be an underlying bug with The 
 Foreman because this error will not appear under modules' expected 
 inheritance.


>>> This is what was posted on The Foreman mail list group:
>>> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion
>>>
 This is an issue with the format of the ENC YAML used between Foreman 
 and Puppet, and is best fixed in the module. 
 The list of classes is given as a hash/dictionary and so has no 
 particular order defined - it's down to the Puppet master/server to 
 iterate over it, and it probably does so in no particular order. It 
 isn't under Foreman's control.
>>>
>>>
>>> I now believe this is truly the root of my problem. 
>>>
>>> The evidence is looking at the ENC output and the Puppet-generated 
>>> Catalog file on each of the master puppet servers.
>>> As you can see below, the puppet-generated catalog on the 
>>> secondary-master puppet server has put rsyslog::client before rsyslog - 
>>> this causes the failure.
>>> However, The Foreman ENC output is the same on both primary and 
>>> secondary master puppet servers.
>>>
>>>
>>
>> You have taken a step backward there.  I remind you that duplicate 
>> declaration errors occur *during catalog building*, and that catalog 
>> building fails if one occurs.  It is therefore impossible to compare a 
>> catalog from the failure case to a catalog from the success case, because 
>> no catalog is ever created in the failure case.
>>
>>
> Then I was mistaken in thinking that the node file 
> (/var/lib/puppet/yaml/node/server1.mydomain.example.com.yaml) was the data 
> (catalog pre-data) written to a file before the catalog compilation 
> procedure.
>


But you said you were looking at the *catalog* not "catalog pre-data". I'm 
sure you appreciate the tremendous difference between those.

 

> I assumed this because both the foreman and node files are created new 
> every time server1 performs a puppet agent update, even when the result is 
> a 400 error for the catalog compilation.
> If I am mistaken in this, then I need someone to tell me how to get the 
> data of the catalog that is failing to be compiled, so that I can compare 
> it with other sources.
>
> Here is the procedure I have been assuming (I am not an expert on puppet 
> internals):
> 1. (server1)puppet-agent -> puppet-master
> 2. puppet-master -> (exec)puppet[external_nodes] 
> server1.mydomain.example.com -> foreman ENC
> 3. foreman ENC -> 
> /var/lib/puppet/yaml/foreman/server1.mydomain.example.com.yaml -> 
> puppet-master
> 4. puppet-master 
> -> /var/lib/puppet/yaml/node/server1.mydomain.example.com.yaml -> 
> puppet-master(compile-catalog)
> 5. puppet-master(compile-catalog) -> Error -> 400 Server Error -> 
> (server1)puppet-agent
>

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

On Tuesday, October 18, 2016 at 9:49:23 AM UTC-5, jcbollinger wrote:
>
>
>
> On Monday, October 17, 2016 at 3:15:51 PM UTC-5, re-g...@wiu.edu wrote:
>>
>>
>>
>> On Friday, October 14, 2016 at 5:08:31 PM UTC-5, re-g...@wiu.edu wrote:
>>>
>>>
>>>
>>> On Thursday, October 13, 2016 at 9:15:58 AM UTC-5, Rob Nelson wrote:

 I've worked with saz in the past and believe he would be very receptive 
 to PRs that address this issue, as well, if RG or anyone else wanted to 
 contribute them. That would be one of the better solutions to the problem.

 Rob Nelson
 rnel...@gmail.com


 I think I've given you a pretty good handle on the nature of the 
> problem, and I'm inclined to think that a solution that addresses the 
> problem at its root will take care of the whole suite of issues.
>

>>> Lots and lots of thanks to jcbollinger.
>>> Here is what I have done as a result of this thread:
>>>
>>> Submitted an issue with saz-rsyslog:
>>> Duplicate Declaration Class[Rsyslog] with The Foreman as ENC during 
>>> catalog compilation #237
>>> https://github.com/saz/puppet-rsyslog/issues/237
>>>
>>> Posted a follow-up question to a related thread on The Foreman mail list 
>>> to determine if The Foreman also may be exhibiting a bug, or if the issue 
>>> may be my configuration:
>>> Duplicate declaration error.
>>> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion 
>>>   (my post is waiting for approval as of 22:00 GMT 10/14/2016)
>>>
>>> My current thought at this time is two points:
>>> 1. saz-rsyslog is written in such a way that declaring a subclass before 
>>> the parent class causes duplicate declaration errors - but I am told the 
>>> module inheritance should be addressed, and would resolve this issue.
>>> 2. The Foreman, under undetermined circumstances (maybe my 
>>> misconfiguration), will randomly declare parent classes and subclass out of 
>>> order - but I am told this is not an issue with puppet modules that use 
>>> inheritance correctly - thus there might be an underlying bug with The 
>>> Foreman because this error will not appear under modules' expected 
>>> inheritance.
>>>
>>>
>> This is what was posted on The Foreman mail list group:
>> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion
>>
>>> This is an issue with the format of the ENC YAML used between Foreman 
>>> and Puppet, and is best fixed in the module. 
>>> The list of classes is given as a hash/dictionary and so has no 
>>> particular order defined - it's down to the Puppet master/server to 
>>> iterate over it, and it probably does so in no particular order. It 
>>> isn't under Foreman's control.
>>
>>
>> I now believe this is truly the root of my problem. 
>>
>> The evidence is looking at the ENC output and the Puppet-generated 
>> Catalog file on each of the master puppet servers.
>> As you can see below, the puppet-generated catalog on the 
>> secondary-master puppet server has put rsyslog::client before rsyslog - 
>> this causes the failure.
>> However, The Foreman ENC output is the same on both primary and secondary 
>> master puppet servers.
>>
>>
>
> You have taken a step backward there.  I remind you that duplicate 
> declaration errors occur *during catalog building*, and that catalog 
> building fails if one occurs.  It is therefore impossible to compare a 
> catalog from the failure case to a catalog from the success case, because 
> no catalog is ever created in the failure case.
>
>
Then I was mistaken in thinking that the node file 
(/var/lib/puppet/yaml/node/server1.mydomain.example.com.yaml) was the data 
(catalog pre-data) written to a file before the catalog compilation 
procedure.
I assumed this because both the foreman and node files are created new 
every time server1 performs a puppet agent update, even when the result is 
a 400 error for the catalog compilation.
If I am mistaken in this, then I need someone to tell me how to get the 
data of the catalog that is failing to be compiled, so that I can compare 
it with other sources.

Here is the procedure I have been assuming (I am not an expert on puppet 
internals):
1. (server1)puppet-agent -> puppet-master
2. puppet-master -> (exec)puppet[external_nodes] 
server1.mydomain.example.com -> foreman ENC
3. foreman ENC -> 
/var/lib/puppet/yaml/foreman/server1.mydomain.example.com.yaml -> 
puppet-master
4. puppet-master 
-> /var/lib/puppet/yaml/node/server1.mydomain.example.com.yaml -> 
puppet-master(compile-catalog)
5. puppet-master(compile-catalog) -> Error -> 400 Server Error -> 
(server1)puppet-agent

I was assuming the node file is the data of the catalog to be compiled. I 
had noticed it is updated in every puppet agent run, even when the run is 
in error. And it was the differing piece between primary and secondary 
puppet masters.
Please correct me.
Please let me know how to get the data of the catalog the puppet master is 
failing to compile for the puppet agent.
 

> It is

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

On Monday, October 17, 2016 at 5:00:14 PM UTC-5, Rob Nelson wrote:
>
> RG,
>
> I ultimately do not know the answer to your question (though I believe it 
> may be due to the non-deterministic ordering when resources are not 
> specifically ordered), however you should note that your primary service 
> includes *"rsyslog::client"* and the secondary includes *rsyslog::client* 
> (without the quotes). I am not sure if that is a red herring or if it means 
> there is an actual difference in the delivered catalog and how puppet agent 
> evaluates it, though it does seem odd that the ENC output has that slight 
> variation between systems.
>
>
Argh! Sorry about that, that was my copy-paste error.
I went back and double-checked. The primary-puppet foreman output with 
without the quotes. The primary-puppet node output is with the quotes. in 
the node output, every subclass is enclosed in double-quotes because it has 
double-colons in the name string.
The primary and secondary puppet masters have the same foreman output file, 
which is the same for rsyslog,rsyslog::* in the primary-puppet node output 
file. I must have copied from the wrong screen because they looked the 
same, and then overlooked the double-quotes when double-checking my work.



> Rob Nelson
> rnel...@gmail.com 
>
> On Mon, Oct 17, 2016 at 4:15 PM, > wrote:
>
>>
>>
>> On Friday, October 14, 2016 at 5:08:31 PM UTC-5, re-g...@wiu.edu wrote:
>>>
>>>
>>>
>>> On Thursday, October 13, 2016 at 9:15:58 AM UTC-5, Rob Nelson wrote:

 I've worked with saz in the past and believe he would be very receptive 
 to PRs that address this issue, as well, if RG or anyone else wanted to 
 contribute them. That would be one of the better solutions to the problem.

 Rob Nelson
 rnel...@gmail.com


 I think I've given you a pretty good handle on the nature of the 
> problem, and I'm inclined to think that a solution that addresses the 
> problem at its root will take care of the whole suite of issues.
>

>>> Lots and lots of thanks to jcbollinger.
>>> Here is what I have done as a result of this thread:
>>>
>>> Submitted an issue with saz-rsyslog:
>>> Duplicate Declaration Class[Rsyslog] with The Foreman as ENC during 
>>> catalog compilation #237
>>> https://github.com/saz/puppet-rsyslog/issues/237
>>>
>>> Posted a follow-up question to a related thread on The Foreman mail list 
>>> to determine if The Foreman also may be exhibiting a bug, or if the issue 
>>> may be my configuration:
>>> Duplicate declaration error.
>>> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion 
>>>   (my post is waiting for approval as of 22:00 GMT 10/14/2016)
>>>
>>> My current thought at this time is two points:
>>> 1. saz-rsyslog is written in such a way that declaring a subclass before 
>>> the parent class causes duplicate declaration errors - but I am told the 
>>> module inheritance should be addressed, and would resolve this issue.
>>> 2. The Foreman, under undetermined circumstances (maybe my 
>>> misconfiguration), will randomly declare parent classes and subclass out of 
>>> order - but I am told this is not an issue with puppet modules that use 
>>> inheritance correctly - thus there might be an underlying bug with The 
>>> Foreman because this error will not appear under modules' expected 
>>> inheritance.
>>>
>>>
>> This is what was posted on The Foreman mail list group:
>> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion
>>
>>> This is an issue with the format of the ENC YAML used between Foreman 
>>> and Puppet, and is best fixed in the module. 
>>> The list of classes is given as a hash/dictionary and so has no 
>>> particular order defined - it's down to the Puppet master/server to 
>>> iterate over it, and it probably does so in no particular order. It 
>>> isn't under Foreman's control.
>>
>>
>> I now believe this is truly the root of my problem. 
>>
>> The evidence is looking at the ENC output and the Puppet-generated 
>> Catalog file on each of the master puppet servers.
>> As you can see below, the puppet-generated catalog on the 
>> secondary-master puppet server has put rsyslog::client before rsyslog - 
>> this causes the failure.
>> However, The Foreman ENC output is the same on both primary and secondary 
>> master puppet servers.
>>
>> Is this correct, that the yaml file in /var/lib/puppet/yaml/node/ is 
>> exclusively generated by Puppet based on the ENC yaml?
>> If this is correct, then this is the root of the problem.
>>
>> The next question is, why does Puppet assemble a catalog with classes out 
>> of order, when the ENC output has them in the correct order?
>> I have seen two answers to this question of classes getting out of order 
>> in the puppet catalog:
>>  1. one class 'cA' depends on 'cB', so puppet puts 'cB' first in the 
>> catalog. - but this is not the reason in my case.
>>  2. "... If you do not see the error on every run then it is modulated by 
>

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[jcbollinger]

On Monday, October 17, 2016 at 3:15:51 PM UTC-5, re-g...@wiu.edu wrote:
>
>
>
> On Friday, October 14, 2016 at 5:08:31 PM UTC-5, re-g...@wiu.edu wrote:
>>
>>
>>
>> On Thursday, October 13, 2016 at 9:15:58 AM UTC-5, Rob Nelson wrote:
>>>
>>> I've worked with saz in the past and believe he would be very receptive 
>>> to PRs that address this issue, as well, if RG or anyone else wanted to 
>>> contribute them. That would be one of the better solutions to the problem.
>>>
>>> Rob Nelson
>>> rnel...@gmail.com
>>>
>>>
>>> I think I've given you a pretty good handle on the nature of the 
 problem, and I'm inclined to think that a solution that addresses the 
 problem at its root will take care of the whole suite of issues.

>>>
>> Lots and lots of thanks to jcbollinger.
>> Here is what I have done as a result of this thread:
>>
>> Submitted an issue with saz-rsyslog:
>> Duplicate Declaration Class[Rsyslog] with The Foreman as ENC during 
>> catalog compilation #237
>> https://github.com/saz/puppet-rsyslog/issues/237
>>
>> Posted a follow-up question to a related thread on The Foreman mail list 
>> to determine if The Foreman also may be exhibiting a bug, or if the issue 
>> may be my configuration:
>> Duplicate declaration error.
>> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion   
>> (my post is waiting for approval as of 22:00 GMT 10/14/2016)
>>
>> My current thought at this time is two points:
>> 1. saz-rsyslog is written in such a way that declaring a subclass before 
>> the parent class causes duplicate declaration errors - but I am told the 
>> module inheritance should be addressed, and would resolve this issue.
>> 2. The Foreman, under undetermined circumstances (maybe my 
>> misconfiguration), will randomly declare parent classes and subclass out of 
>> order - but I am told this is not an issue with puppet modules that use 
>> inheritance correctly - thus there might be an underlying bug with The 
>> Foreman because this error will not appear under modules' expected 
>> inheritance.
>>
>>
> This is what was posted on The Foreman mail list group:
> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion
>
>> This is an issue with the format of the ENC YAML used between Foreman 
>> and Puppet, and is best fixed in the module. 
>> The list of classes is given as a hash/dictionary and so has no 
>> particular order defined - it's down to the Puppet master/server to 
>> iterate over it, and it probably does so in no particular order. It 
>> isn't under Foreman's control.
>
>
> I now believe this is truly the root of my problem. 
>
> The evidence is looking at the ENC output and the Puppet-generated Catalog 
> file on each of the master puppet servers.
> As you can see below, the puppet-generated catalog on the secondary-master 
> puppet server has put rsyslog::client before rsyslog - this causes the 
> failure.
> However, The Foreman ENC output is the same on both primary and secondary 
> master puppet servers.
>
>

You have taken a step backward there.  I remind you that duplicate 
declaration errors occur *during catalog building*, and that catalog 
building fails if one occurs.  It is therefore impossible to compare a 
catalog from the failure case to a catalog from the success case, because 
no catalog is ever created in the failure case.

It is useful to confirm that Foreman's ENC produces consistent output -- if 
indeed it does.  I'm not surprised that you obtained identical ENC output 
from two different Foreman servers, but it's unclear to me whether you have 
compared the failure-case ENC output with the success-case ENC output.  I 
am inclined to guess that these do differ, because clearly *something* 
changes.

Unless 

Do check the the 'ordering' parameter in the [master] section of your 
master's puppet configuration.  If it is specified, and the specified value 
is anything other than 'manifest', then it is possible that setting its 
value to 'manifest' (the default) will help.  I emphasize, however, that 
this is a workaround for sloppy manifest code, not a bona fide solution.

You've made a lot of hay about saz-rsyslog being approved / known-good / 
high-quality, with no particular justification.  Certainly the module being 
available from the Forge should not be interpreted to support such a 
conclusion.  To be clear: having looked at the code of the module in 
question, I think it is generally of good quality.  As I have already said, 
however, and as Dominic Cleal told you over on the Foreman group, the 
fundamental problem here is in the manifests -- *the module's* manifests.  
The module is designed and its manifests are written in a manner that is 
especially conducive to the kind of problem you've encountered.

 

> Is this correct, that the yaml file in /var/lib/puppet/yaml/node/ is 
> exclusively generated by Puppet based on the ENC yaml?
> If this is correct, then this is the root of the problem.
>


I'm not sure what signifi

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[Rob Nelson]

RG,

I ultimately do not know the answer to your question (though I believe it
may be due to the non-deterministic ordering when resources are not
specifically ordered), however you should note that your primary service
includes *"rsyslog::client"* and the secondary includes *rsyslog::client*
(without the quotes). I am not sure if that is a red herring or if it means
there is an actual difference in the delivered catalog and how puppet agent
evaluates it, though it does seem odd that the ENC output has that slight
variation between systems.


Rob Nelson
rnels...@gmail.com

On Mon, Oct 17, 2016 at 4:15 PM,  wrote:

>
>
> On Friday, October 14, 2016 at 5:08:31 PM UTC-5, re-g...@wiu.edu wrote:
>>
>>
>>
>> On Thursday, October 13, 2016 at 9:15:58 AM UTC-5, Rob Nelson wrote:
>>>
>>> I've worked with saz in the past and believe he would be very receptive
>>> to PRs that address this issue, as well, if RG or anyone else wanted to
>>> contribute them. That would be one of the better solutions to the problem.
>>>
>>> Rob Nelson
>>> rnel...@gmail.com
>>>
>>>
>>> I think I've given you a pretty good handle on the nature of the
 problem, and I'm inclined to think that a solution that addresses the
 problem at its root will take care of the whole suite of issues.

>>>
>> Lots and lots of thanks to jcbollinger.
>> Here is what I have done as a result of this thread:
>>
>> Submitted an issue with saz-rsyslog:
>> Duplicate Declaration Class[Rsyslog] with The Foreman as ENC during
>> catalog compilation #237
>> https://github.com/saz/puppet-rsyslog/issues/237
>>
>> Posted a follow-up question to a related thread on The Foreman mail list
>> to determine if The Foreman also may be exhibiting a bug, or if the issue
>> may be my configuration:
>> Duplicate declaration error.
>> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion
>> (my post is waiting for approval as of 22:00 GMT 10/14/2016)
>>
>> My current thought at this time is two points:
>> 1. saz-rsyslog is written in such a way that declaring a subclass before
>> the parent class causes duplicate declaration errors - but I am told the
>> module inheritance should be addressed, and would resolve this issue.
>> 2. The Foreman, under undetermined circumstances (maybe my
>> misconfiguration), will randomly declare parent classes and subclass out of
>> order - but I am told this is not an issue with puppet modules that use
>> inheritance correctly - thus there might be an underlying bug with The
>> Foreman because this error will not appear under modules' expected
>> inheritance.
>>
>>
> This is what was posted on The Foreman mail list group:
> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion
>
>> This is an issue with the format of the ENC YAML used between Foreman
>> and Puppet, and is best fixed in the module.
>> The list of classes is given as a hash/dictionary and so has no
>> particular order defined - it's down to the Puppet master/server to
>> iterate over it, and it probably does so in no particular order. It
>> isn't under Foreman's control.
>
>
> I now believe this is truly the root of my problem.
>
> The evidence is looking at the ENC output and the Puppet-generated Catalog
> file on each of the master puppet servers.
> As you can see below, the puppet-generated catalog on the secondary-master
> puppet server has put rsyslog::client before rsyslog - this causes the
> failure.
> However, The Foreman ENC output is the same on both primary and secondary
> master puppet servers.
>
> Is this correct, that the yaml file in /var/lib/puppet/yaml/node/ is
> exclusively generated by Puppet based on the ENC yaml?
> If this is correct, then this is the root of the problem.
>
> The next question is, why does Puppet assemble a catalog with classes out
> of order, when the ENC output has them in the correct order?
> I have seen two answers to this question of classes getting out of order
> in the puppet catalog:
>  1. one class 'cA' depends on 'cB', so puppet puts 'cB' first in the
> catalog. - but this is not the reason in my case.
>  2. "... If you do not see the error on every run then it is modulated by
> something that varies between runs. That could be almost anything:
> manifests, data, results of function calls, node facts, or ENC output. ..."
> - which should be unlikely since it works on one secondary master and not
> the next secondary master, both configured exactly the same.
>
> Is there a configuration issue causing this issue? Where would I begin
> looking for something that may be causing this puppet-catalog problem?
>
>
> Running `puppet agent -t` on the client against the primary master puppet
> server is successful
> Running `puppet agent -t` on the client against the secondary master
> puppet server fails with duplicate declaration
>
>
> On the primary master puppet server
>
> --The Foreman ENC output--
> primary-puppet:/var/lib/puppet/yaml/foreman/server1.
> mydomain.example.com.yaml
> ...snip...
> r

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

On Friday, October 14, 2016 at 5:08:31 PM UTC-5, re-g...@wiu.edu wrote:
>
>
>
> On Thursday, October 13, 2016 at 9:15:58 AM UTC-5, Rob Nelson wrote:
>>
>> I've worked with saz in the past and believe he would be very receptive 
>> to PRs that address this issue, as well, if RG or anyone else wanted to 
>> contribute them. That would be one of the better solutions to the problem.
>>
>> Rob Nelson
>> rnel...@gmail.com
>>
>>
>> I think I've given you a pretty good handle on the nature of the problem, 
>>> and I'm inclined to think that a solution that addresses the problem at its 
>>> root will take care of the whole suite of issues.
>>>
>>
> Lots and lots of thanks to jcbollinger.
> Here is what I have done as a result of this thread:
>
> Submitted an issue with saz-rsyslog:
> Duplicate Declaration Class[Rsyslog] with The Foreman as ENC during 
> catalog compilation #237
> https://github.com/saz/puppet-rsyslog/issues/237
>
> Posted a follow-up question to a related thread on The Foreman mail list 
> to determine if The Foreman also may be exhibiting a bug, or if the issue 
> may be my configuration:
> Duplicate declaration error.
> https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion   
> (my post is waiting for approval as of 22:00 GMT 10/14/2016)
>
> My current thought at this time is two points:
> 1. saz-rsyslog is written in such a way that declaring a subclass before 
> the parent class causes duplicate declaration errors - but I am told the 
> module inheritance should be addressed, and would resolve this issue.
> 2. The Foreman, under undetermined circumstances (maybe my 
> misconfiguration), will randomly declare parent classes and subclass out of 
> order - but I am told this is not an issue with puppet modules that use 
> inheritance correctly - thus there might be an underlying bug with The 
> Foreman because this error will not appear under modules' expected 
> inheritance.
>
>
This is what was posted on The Foreman mail list group:
https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion

> This is an issue with the format of the ENC YAML used between Foreman 
> and Puppet, and is best fixed in the module. 
> The list of classes is given as a hash/dictionary and so has no 
> particular order defined - it's down to the Puppet master/server to 
> iterate over it, and it probably does so in no particular order. It 
> isn't under Foreman's control.


I now believe this is truly the root of my problem. 

The evidence is looking at the ENC output and the Puppet-generated Catalog 
file on each of the master puppet servers.
As you can see below, the puppet-generated catalog on the secondary-master 
puppet server has put rsyslog::client before rsyslog - this causes the 
failure.
However, The Foreman ENC output is the same on both primary and secondary 
master puppet servers.

Is this correct, that the yaml file in /var/lib/puppet/yaml/node/ is 
exclusively generated by Puppet based on the ENC yaml?
If this is correct, then this is the root of the problem.

The next question is, why does Puppet assemble a catalog with classes out 
of order, when the ENC output has them in the correct order?
I have seen two answers to this question of classes getting out of order in 
the puppet catalog:
 1. one class 'cA' depends on 'cB', so puppet puts 'cB' first in the 
catalog. - but this is not the reason in my case.
 2. "... If you do not see the error on every run then it is modulated by 
something that varies between runs. That could be almost anything: 
manifests, data, results of function calls, node facts, or ENC output. ..." 
- which should be unlikely since it works on one secondary master and not 
the next secondary master, both configured exactly the same.

Is there a configuration issue causing this issue? Where would I begin 
looking for something that may be causing this puppet-catalog problem?


Running `puppet agent -t` on the client against the primary master puppet 
server is successful
Running `puppet agent -t` on the client against the secondary master puppet 
server fails with duplicate declaration


On the primary master puppet server

--The Foreman ENC output--
primary-puppet:/var/lib/puppet/yaml/foreman/server1.mydomain.example.com.yaml
...snip...
rsyslog: 
  gnutls_package_name: false
  preserve_fqdn: true
  relp_package_name: false
  rsyslog_package_name: false
"rsyslog::client": 
  log_local: true
  remote_type: udp
  server: rsyslog.mydomain.example.com
...snip...
--end--

--Puppet generated catalog--
primary-puppet:/var/lib/puppet/yaml/node/server1.mydomain.example.com.yaml
rsyslog: 
  gnutls_package_name: false
  preserve_fqdn: true
  relp_package_name: false
  rsyslog_package_name: false
"rsyslog::client": 
  log_local: true
  remote_type: udp
  server: rsyslog.mydomain.example.com
--end--


On the secondary master puppet server

--The Foreman ENC output--
secondary-puppet:/var/lib/pup

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

On Thursday, October 13, 2016 at 9:15:58 AM UTC-5, Rob Nelson wrote:
>
> I've worked with saz in the past and believe he would be very receptive to 
> PRs that address this issue, as well, if RG or anyone else wanted to 
> contribute them. That would be one of the better solutions to the problem.
>
> Rob Nelson
> rnel...@gmail.com 
>
>
> I think I've given you a pretty good handle on the nature of the problem, 
>> and I'm inclined to think that a solution that addresses the problem at its 
>> root will take care of the whole suite of issues.
>>
>
Lots and lots of thanks to jcbollinger.
Here is what I have done as a result of this thread:

Submitted an issue with saz-rsyslog:
Duplicate Declaration Class[Rsyslog] with The Foreman as ENC during catalog 
compilation #237
https://github.com/saz/puppet-rsyslog/issues/237

Posted a follow-up question to a related thread on The Foreman mail list to 
determine if The Foreman also may be exhibiting a bug, or if the issue may 
be my configuration:
Duplicate declaration error.
https://groups.google.com/d/topic/foreman-users/k0JgABtszdU/discussion   
(my post is waiting for approval as of 22:00 GMT 10/14/2016)

My current thought at this time is two points:
1. saz-rsyslog is written in such a way that declaring a subclass before 
the parent class causes duplicate declaration errors - but I am told the 
module inheritance should be addressed, and would resolve this issue.
2. The Foreman, under undetermined circumstances (maybe my 
misconfiguration), will randomly declare parent classes and subclass out of 
order - but I am told this is not an issue with puppet modules that use 
inheritance correctly - thus there might be an underlying bug with The 
Foreman because this error will not appear under modules' expected 
inheritance.

-- 
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/dea74d38-538c-4d49-93a7-4c8e9acce1de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[Rob Nelson]

I've worked with saz in the past and believe he would be very receptive to
PRs that address this issue, as well, if RG or anyone else wanted to
contribute them. That would be one of the better solutions to the problem.

Rob Nelson
rnels...@gmail.com


I think I've given you a pretty good handle on the nature of the problem,
> and I'm inclined to think that a solution that addresses the problem at its
> root will take care of the whole suite of issues.
>

-- 
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/CAC76iT_E-WbqpDj8F%3DmwE4_rbRAchCBATqDxK%2B-6%2BS57EE006w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[jcbollinger]

On Wednesday, October 12, 2016 at 4:15:51 PM UTC-5, re-g...@wiu.edu wrote:
 

> You were right, that catalog file 
> (server1:/var/lib/puppet/client_data/catalog/server1.mydomain.example.com.json)
>  
> was from a successful build/run. There is no new catalog file when the 
> server1 node receives the duplicate declaration error.
>
> I did some further testing, and I hope I made a little progress on 
> narrowing down the issue - perhaps this adds a clue:
>
> Summary:
>  1. Both rsyslog and rsyslog::client are assigned to the node server1 via 
> a class group in The Foreman
>  2. When I remove the rsyslog::client assignment, the server1 node can 
> perform a successful puppet update, without a duplicate declaration error
>


That confirms what I have been saying all along.  Class rsyslog::client is 
a subclass of rsyslog (which is not true of most of the other rsyslog::* 
classes).  If you declare that class at all, with or without parameters, 
then you must not declare any parameters for class rsyslog.  If you want 
non-default parameters for class rsyslog then it must get them via 
automated data binding.

Technically, in fact, the module violates the DSL specifications 
 
by having rsyslog::client inherit from a parameterized class at all.  In 
practice, that combination normally works as desired, provided that any 
parameterized direct declaration of the base class is evaluated before all 
declarations of the subclass.  Evaluation-order dependencies such as this 
can be very difficult to deal with, and should be avoided at all costs.  
This is the primary reason why the resource-like class declaration syntax, 
as it was designed and implemented, was a bad idea from the very beginning.

 

>  3. Then I added rsyslog::client assignment back into the group, I 
> received the duplicate declaration error
>  4. Then, one parameter at a time, I configured The Foreman to use the 
> "default value" (checked the "use default" box) of each configured 
> parameter for the node server1, when this fact matches: fqdn=
> server1.mydomain.example.com
>  5. When all parameters are set to be "default value" for this node, even 
> though the class is still assigned to the node via The Foreman, and even 
> though the parameters are still set to a value for other nodes via The 
> Foreman, the puppet update runs successfully without a duplicate 
> declaration error on node server1
>


I suspect that if you look at the output of Foreman's ENC then you will 
find that the declaration of class rsyslog::client is different in the case 
where all parameters are set to take "default value" than when any 
parameter is assigned an explicit value.  Although I have not probed this 
before, it would be logical for Puppet to evaluate the ENC-derived 
declarations in this order:

   1. global variable assignments
   2. class declarations with explicit parameters (which are in a different 
   section of the ENC output from ...)
   3. class declarations without explicit parameters

If indeed Puppet does this, then that accounts for the behavior you 
describe by ensuring that class rsyslog is evaluated before rsyslog::client 
when no parameter values are specified for the latter.  (I re-emphasize 
that this makes a difference only because the module does not conform to 
the DSL specifications.) It seems that when both classes have parameter 
values assigned to them via The Foreman, then rsyslog::client is evaluated 
first, yielding the error; I have speculations about why that may be, but 
no solid information.

 

>  6. After this, my going back and setting just one parameter in the 
> rsyslog::client class for this node causes the duplicate declaration error
>
>

Yes, that's consistent with everything else you said.

 

> Details:
>
> In The Foreman, I have a Puppet Class config group that I assign to the 
> group of hosts in this remote location. I assign this same config group for 
> every node in the network, even ones in the local network and other remote 
> networks that do not experience duplicate class errors. Let me call this 
> group DefG1.
>
> The DefG1 config group has my default puppet module classes defined in it, 
> including the Rsyslog puppet module class.
> However, I am including a subclass rsyslog::client in addition to the main 
> class rsyslog in this group DefG1. Because I need to configure the rsyslog 
> client parameters for every node, namely the remote syslog server host.
> Now, this is not an issue with other puppet modules to include sub modules 
> (for example I also use both foreman-puppet and foreman-puppet::config 
> together without issue).
>


Again, the saz-rsyslog module has flaws that make its use susceptible to 
the kind of error you are experiencing.  The problem is not inherent in 
direct use, with or without parameters, of multiple classes from the same 
module, nor does it reflect a bug in Puppet or The Foreman.  One coul

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

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

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

On Wednesday, October 12, 2016 at 7:59:25 AM UTC-5, 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]).
>>
>> 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.
>>
>>
>
> A duplicate declaration error is a parse (i.e. catalog building) error.  
> If the master encounters one then it does not emit a catalog -- or if it 
> did, it could not be one based on the failed catalog-building attempt.  I'm 
> not sure what you're looking at, but it does not have the significance you 
> are attributing to it.
>
>  
>
>> 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?
>>
>
>
> No.  Any catalog you have is the result of a catalog-building run in which 
> no such error was produced.
>
> The appearance of duplicate declaration errors can be sensitive to the 
> order of declarations in your manifests or ENC output, but a catalog does 
> not directly inform about that.
>
>
> John
>
>
You were right, that catalog file 
(server1:/var/lib/puppet/client_data/catalog/ser

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[Henrik Lindberg]

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.

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[jcbollinger]

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]).
>
> 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.
>
>

A duplicate declaration error is a parse (i.e. catalog building) error.  If 
the master encounters one then it does not emit a catalog -- or if it did, 
it could not be one based on the failed catalog-building attempt.  I'm not 
sure what you're looking at, but it does not have the significance you are 
attributing to it.

 

> 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?
>


No.  Any catalog you have is the result of a catalog-building run in which 
no such error was produced.

The appearance of duplicate declaration errors can be sensitive to the 
order of declarations in your manifests or ENC output, but a catalog does 
not directly inform about that.


John

-- 
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/m

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

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]).

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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/385f8838-9518-4d1f-87a2-6e77

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[jcbollinger]

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

-- 
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/e6387508-1112-4bc5-bb4d-85bfe7656459%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

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 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.

At this particular moment, all of the nodes experiencing the duplicate 
class declaration error are accessing the secondary-master puppet server. 
Not all nodes connecting to this secondary-master are experiencing this 
issue however - only 13 out of 33 nodes.
Also, I have other secondary-master servers on other segments. And nodes 
getting updates from those have experienced this error before too. However, 
I do not recall it occurring recently.
I cannot remember if a node connecting to the primary-master has 
experienced this issue - I want to say yes, but cannot recall to be certain.


On Friday, October 7, 2016 at 8:52:20 AM UTC-5, Rob Nelson wrote:
>
> Not being a foreman user, I can't add a whole lot of detail to this, but 
> it does SEEM like there's something in the foreman "extras" that may be 
> conflicting with the direct puppet code in certain situations. My 
> understanding is that it provides some sort of overlay, and that could 
> definitely cause a conflict - it's easy with PE, for instance, to have the 
> Node Classifier and your puppet manifests on disk have collisions without 
> being obvious. I would look at what the "overlay" provides - whatever the 
> proper term is for it.
>
>
> Rob Nelson
> rnel...@gmail.com 
>
> On Fri, Oct 7, 2016 at 9:48 AM, > wrote:
>
>> On Thursday, October 6, 2016 at 12:23:40 PM UTC-5, Rob Nelson wrote:
>>>
>>> Can you undo the change in foreman, see if the problem goes away, then 
>>> reimplement the change and see if the problem comes back? That would go a 
>>> long way toward isolating the cause. 
>>>
>>>
>> So I removed the rsyslog configuration from the foreman, the problem 
>> disappeared, then I added the rsyslog configuration back in and the problem 
>> immediately reappeared.
>>
>> The other configuration we added at 9:00am-ish  well we since added 
>> some very minor configuration changes for host parameters in the afternoon, 
>> and this problem went away. Nothing was touched after that. Then about 6 
>> hours ago, at 2:00am-ish, the problem reappeared.
>> Then I removed the rsyslog configuration, after which the problem 
>> disappeared, then I re-added the rsyslog configuration and the problem 
>> reappeared.
>>
>>  
>>
>>> On Thursday, October 6, 2016,  wrote:
>>>


 On Wednesday, October 5, 2016 at 2:32:37 PM UTC-5, re-g...@wiu.edu 
 wrote:
>
> I installed the puppet module saz-rsyslog from puppet forge.
> I use The Foreman to configure nodes. The Foreman is used by puppet 
> via configuration [master] "external_nodes" "/etc/puppet/node.rb"
>
> Since the saz-rsyslog module install, I have been receiving the 
> following error off and on (not consistently) across many nodes on a 
> puppet 
> update (i.e. puppet agent -t):
>
> "Could not retrieve catalog from remote server: Error 400 on SERVER: 
> Duplicate declaration: Class[Rsyslog] is already declared; cannot 
> redeclare 
> on node "
>
>
> My nodes are CentOS 5,6,7; and any various number of the nodes may 
> experience this issue, but not all of them at the same time.
>
> One day I will see dozens of server with this error, and other nodes 
> not having this issue. This may go on for days if I do not touch The 
> Foreman.
> I'll make some changes to host configuration for puppet module class 
> parameters in The Foreman - never the saz-rsyslog module th

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[Rob Nelson]

Not being a foreman user, I can't add a whole lot of detail to this, but it
does SEEM like there's something in the foreman "extras" that may be
conflicting with the direct puppet code in certain situations. My
understanding is that it provides some sort of overlay, and that could
definitely cause a conflict - it's easy with PE, for instance, to have the
Node Classifier and your puppet manifests on disk have collisions without
being obvious. I would look at what the "overlay" provides - whatever the
proper term is for it.


Rob Nelson
rnels...@gmail.com

On Fri, Oct 7, 2016 at 9:48 AM,  wrote:

> On Thursday, October 6, 2016 at 12:23:40 PM UTC-5, Rob Nelson wrote:
>>
>> Can you undo the change in foreman, see if the problem goes away, then
>> reimplement the change and see if the problem comes back? That would go a
>> long way toward isolating the cause.
>>
>>
> So I removed the rsyslog configuration from the foreman, the problem
> disappeared, then I added the rsyslog configuration back in and the problem
> immediately reappeared.
>
> The other configuration we added at 9:00am-ish  well we since added
> some very minor configuration changes for host parameters in the afternoon,
> and this problem went away. Nothing was touched after that. Then about 6
> hours ago, at 2:00am-ish, the problem reappeared.
> Then I removed the rsyslog configuration, after which the problem
> disappeared, then I re-added the rsyslog configuration and the problem
> reappeared.
>
>
>
>> On Thursday, October 6, 2016,  wrote:
>>
>>>
>>>
>>> On Wednesday, October 5, 2016 at 2:32:37 PM UTC-5, re-g...@wiu.edu
>>> wrote:

 I installed the puppet module saz-rsyslog from puppet forge.
 I use The Foreman to configure nodes. The Foreman is used by puppet via
 configuration [master] "external_nodes" "/etc/puppet/node.rb"

 Since the saz-rsyslog module install, I have been receiving the
 following error off and on (not consistently) across many nodes on a puppet
 update (i.e. puppet agent -t):

 "Could not retrieve catalog from remote server: Error 400 on SERVER:
 Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare
 on node "


 My nodes are CentOS 5,6,7; and any various number of the nodes may
 experience this issue, but not all of them at the same time.

 One day I will see dozens of server with this error, and other nodes
 not having this issue. This may go on for days if I do not touch The
 Foreman.
 I'll make some changes to host configuration for puppet module class
 parameters in The Foreman - never the saz-rsyslog module though..
 After the changes, half or more of the servers having issue (not all)
 will magically have no problems.
 However, more nodes that did not have issues before, will now
 experience this issue.

 Also, this change of events is not directly related to The Foreman host
 configuration changes.
 I can simply perform a puppet module upgrade to a unrelated module
 (e.g. mine-yumconfig). After upgrading the unrelated module, again many
 nodes with this issue will now have it resolved, and different ones not
 experiencing the issue before will now begin experiencing it.


 The only clue I have is from this posting: http://grokbase.com/t
 /gg/puppet-users/165h0exgez/duplicate-resource-declaration-error
 "... If you do not see the error on every run then it is modulated by
 something that varies between runs. That could be almost anything:
 manifests, data, results of function calls, node facts, or ENC output. ..."


 Can anyone help me understand this issue, or help me get it resolved
 permanently?

 When I search for answers, all I see are "You have written a duplicate
 class in your module." However, in my case, I did not write the saz-rsyslog
 module, I am only using it. It is a puppet-forge approved module with
 635,000+ downloads. And without modifying the module, the issue can
 disappear, seemingly without rhyme or reason.

 -RG

>>>
>>>
>>> Some more information
>>>
>>> I am using the latest version of the saz-rsyslog puppet module, version
>>> 4.0.3
>>> https://forge.puppet.com/saz/rsyslog
>>>
>>> As an example, I have this node called h1pa
>>> Yesterday afternoon this node was getting the reported duplicate
>>> Class[Rsyslog] declaration error
>>> The 12:15am update was the last report of this error
>>> The 12:45am update was the first clean update today
>>> In fact, I had 0 nodes reporting this error
>>>
>>> About 9:00am-ish we added a subnet and hostgroup to The Foreman. However
>>> we have not added any new nodes, nor changed the configuration to any
>>> existing nodes.
>>>
>>> Then, I started getting the error again
>>> The 9:15am update was the first report of this error this late morning
>>> The 9:45am update reported this error again
>>> My nodes reporting an error o

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

On Thursday, October 6, 2016 at 12:23:40 PM UTC-5, Rob Nelson wrote:
>
> Can you undo the change in foreman, see if the problem goes away, then 
> reimplement the change and see if the problem comes back? That would go a 
> long way toward isolating the cause. 
>
>
So I removed the rsyslog configuration from the foreman, the problem 
disappeared, then I added the rsyslog configuration back in and the problem 
immediately reappeared.

The other configuration we added at 9:00am-ish  well we since added 
some very minor configuration changes for host parameters in the afternoon, 
and this problem went away. Nothing was touched after that. Then about 6 
hours ago, at 2:00am-ish, the problem reappeared.
Then I removed the rsyslog configuration, after which the problem 
disappeared, then I re-added the rsyslog configuration and the problem 
reappeared.

 

> On Thursday, October 6, 2016, > wrote:
>
>>
>>
>> On Wednesday, October 5, 2016 at 2:32:37 PM UTC-5, re-g...@wiu.edu wrote:
>>>
>>> I installed the puppet module saz-rsyslog from puppet forge.
>>> I use The Foreman to configure nodes. The Foreman is used by puppet via 
>>> configuration [master] "external_nodes" "/etc/puppet/node.rb"
>>>
>>> Since the saz-rsyslog module install, I have been receiving the 
>>> following error off and on (not consistently) across many nodes on a puppet 
>>> update (i.e. puppet agent -t):
>>>
>>> "Could not retrieve catalog from remote server: Error 400 on SERVER: 
>>> Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare 
>>> on node "
>>>
>>>
>>> My nodes are CentOS 5,6,7; and any various number of the nodes may 
>>> experience this issue, but not all of them at the same time.
>>>
>>> One day I will see dozens of server with this error, and other nodes not 
>>> having this issue. This may go on for days if I do not touch The Foreman.
>>> I'll make some changes to host configuration for puppet module class 
>>> parameters in The Foreman - never the saz-rsyslog module though..
>>> After the changes, half or more of the servers having issue (not all) 
>>> will magically have no problems.
>>> However, more nodes that did not have issues before, will now experience 
>>> this issue.
>>>
>>> Also, this change of events is not directly related to The Foreman host 
>>> configuration changes.
>>> I can simply perform a puppet module upgrade to a unrelated module (e.g. 
>>> mine-yumconfig). After upgrading the unrelated module, again many nodes 
>>> with this issue will now have it resolved, and different ones not 
>>> experiencing the issue before will now begin experiencing it.
>>>
>>>
>>> The only clue I have is from this posting: 
>>> http://grokbase.com/t/gg/puppet-users/165h0exgez/duplicate-resource-declaration-error
>>> "... If you do not see the error on every run then it is modulated by 
>>> something that varies between runs. That could be almost anything: 
>>> manifests, data, results of function calls, node facts, or ENC output. ..."
>>>
>>>
>>> Can anyone help me understand this issue, or help me get it resolved 
>>> permanently?
>>>
>>> When I search for answers, all I see are "You have written a duplicate 
>>> class in your module." However, in my case, I did not write the saz-rsyslog 
>>> module, I am only using it. It is a puppet-forge approved module with 
>>> 635,000+ downloads. And without modifying the module, the issue can 
>>> disappear, seemingly without rhyme or reason.
>>>
>>> -RG
>>>
>>
>>
>> Some more information
>>
>> I am using the latest version of the saz-rsyslog puppet module, version 
>> 4.0.3
>> https://forge.puppet.com/saz/rsyslog
>>
>> As an example, I have this node called h1pa
>> Yesterday afternoon this node was getting the reported duplicate 
>> Class[Rsyslog] declaration error
>> The 12:15am update was the last report of this error 
>> The 12:45am update was the first clean update today
>> In fact, I had 0 nodes reporting this error
>>
>> About 9:00am-ish we added a subnet and hostgroup to The Foreman. However 
>> we have not added any new nodes, nor changed the configuration to any 
>> existing nodes.
>>
>> Then, I started getting the error again
>> The 9:15am update was the first report of this error this late morning
>> The 9:45am update reported this error again
>> My nodes reporting an error of this duplicate Class[Rsyslog] error 
>> increased from 0 to 12.
>>
>> All node reports with this error are similar to h1pa node's reports.
>> I am seeing that many of the hosts experiencing this issue yesterday, are 
>> now experiencing it again.
>>
>> -RG
>>
>>
>>
>>
>>
>>
>>  
>>
>> -- 
>> 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/a81931c8-14b3-46d8-94ba-1f31c4c4453a%40googlegroups.com
>>  
>

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[Rob Nelson]

Can you undo the change in foreman, see if the problem goes away, then
reimplement the change and see if the problem comes back? That would go a
long way toward isolating the cause.

On Thursday, October 6, 2016,  wrote:

>
>
> On Wednesday, October 5, 2016 at 2:32:37 PM UTC-5, re-g...@wiu.edu
>  wrote:
>>
>> I installed the puppet module saz-rsyslog from puppet forge.
>> I use The Foreman to configure nodes. The Foreman is used by puppet via
>> configuration [master] "external_nodes" "/etc/puppet/node.rb"
>>
>> Since the saz-rsyslog module install, I have been receiving the following
>> error off and on (not consistently) across many nodes on a puppet update
>> (i.e. puppet agent -t):
>>
>> "Could not retrieve catalog from remote server: Error 400 on SERVER:
>> Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare
>> on node "
>>
>>
>> My nodes are CentOS 5,6,7; and any various number of the nodes may
>> experience this issue, but not all of them at the same time.
>>
>> One day I will see dozens of server with this error, and other nodes not
>> having this issue. This may go on for days if I do not touch The Foreman.
>> I'll make some changes to host configuration for puppet module class
>> parameters in The Foreman - never the saz-rsyslog module though..
>> After the changes, half or more of the servers having issue (not all)
>> will magically have no problems.
>> However, more nodes that did not have issues before, will now experience
>> this issue.
>>
>> Also, this change of events is not directly related to The Foreman host
>> configuration changes.
>> I can simply perform a puppet module upgrade to a unrelated module (e.g.
>> mine-yumconfig). After upgrading the unrelated module, again many nodes
>> with this issue will now have it resolved, and different ones not
>> experiencing the issue before will now begin experiencing it.
>>
>>
>> The only clue I have is from this posting: http://grokbase.com/t
>> /gg/puppet-users/165h0exgez/duplicate-resource-declaration-error
>> "... If you do not see the error on every run then it is modulated by
>> something that varies between runs. That could be almost anything:
>> manifests, data, results of function calls, node facts, or ENC output. ..."
>>
>>
>> Can anyone help me understand this issue, or help me get it resolved
>> permanently?
>>
>> When I search for answers, all I see are "You have written a duplicate
>> class in your module." However, in my case, I did not write the saz-rsyslog
>> module, I am only using it. It is a puppet-forge approved module with
>> 635,000+ downloads. And without modifying the module, the issue can
>> disappear, seemingly without rhyme or reason.
>>
>> -RG
>>
>
>
> Some more information
>
> I am using the latest version of the saz-rsyslog puppet module, version
> 4.0.3
> https://forge.puppet.com/saz/rsyslog
>
> As an example, I have this node called h1pa
> Yesterday afternoon this node was getting the reported duplicate
> Class[Rsyslog] declaration error
> The 12:15am update was the last report of this error
> The 12:45am update was the first clean update today
> In fact, I had 0 nodes reporting this error
>
> About 9:00am-ish we added a subnet and hostgroup to The Foreman. However
> we have not added any new nodes, nor changed the configuration to any
> existing nodes.
>
> Then, I started getting the error again
> The 9:15am update was the first report of this error this late morning
> The 9:45am update reported this error again
> My nodes reporting an error of this duplicate Class[Rsyslog] error
> increased from 0 to 12.
>
> All node reports with this error are similar to h1pa node's reports.
> I am seeing that many of the hosts experiencing this issue yesterday, are
> now experiencing it again.
>
> -RG
>
>
>
>
>
>
>
>
> --
> 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/a81931c8-14b3-46d8-94ba-1f31c4c4453a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 

Rob Nelson
rnels...@gmail.com

-- 
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/CAC76iT-PtvNQvFt2rp6YKrX_wMNuCMQLsgVrxHig3pxCEWf1Lg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[re-glaue]

On Wednesday, October 5, 2016 at 3:58:38 PM UTC-5, Rob Nelson wrote:
>
> RG, typically the Duplication declaration message is followed by some 
> indicator of the file where it is duplicated and the line number. Are you 
> receiving that information and maybe snipped it off the end of the message 
> you included? An alternative might be any sort of `hiera_include()` or 
> `create_resources()` calls whose arguments may include `rsyslog` more than 
> once.
>
> Here is the complete output when running `puppet agent -t`:
[Linux ~]# puppet agent -t
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Loading facts
Error: Could not retrieve catalog from remote server: Error 400 on SERVER: 
Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare 
on node server1.mydomain.test1.example.com

Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run
[Linux ~]#



> Rob Nelson
> rnel...@gmail.com 
>
> On Wed, Oct 5, 2016 at 3:16 PM, > wrote:
>
>> I installed the puppet module saz-rsyslog from puppet forge.
>> I use The Foreman to configure nodes. The Foreman is used by puppet via 
>> configuration [master] "external_nodes" "/etc/puppet/node.rb"
>>
>> Since the saz-rsyslog module install, I have been receiving the following 
>> error off and on (not consistently) across many nodes on a puppet update 
>> (i.e. puppet agent -t):
>>
>> "Could not retrieve catalog from remote server: Error 400 on SERVER: 
>> Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare 
>> on node "
>>
>>
>> My nodes are CentOS 5,6,7; and any various number of the nodes may 
>> experience this issue, but not all of them at the same time.
>>
>> One day I will see dozens of server with this error, and other nodes not 
>> having this issue. This may go on for days if I do not touch The Foreman.
>> I'll make some changes to host configuration for puppet module class 
>> parameters in The Foreman - never the saz-rsyslog module though..
>> After the changes, half or more of the servers having issue (not all) 
>> will magically have no problems.
>> However, more nodes that did not have issues before, will now experience 
>> this issue.
>>
>> Also, this change of events is not directly related to The Foreman host 
>> configuration changes.
>> I can simply perform a puppet module upgrade to a unrelated module (e.g. 
>> mine-yumconfig). After upgrading the unrelated module, again many nodes 
>> with this issue will now have it resolved, and different ones not 
>> experiencing the issue before will now begin experiencing it.
>>
>>
>> The only clue I have is from this posting: 
>> http://grokbase.com/t/gg/puppet-users/165h0exgez/duplicate-resource-declaration-error
>> "... If you do not see the error on every run then it is modulated by 
>> something that varies between runs. That could be almost anything: 
>> manifests, data, results of function calls, node facts, or ENC output. ..."
>>
>>
>> Can anyone help me understand this issue, or help me get it resolved 
>> permanently?
>>
>> When I search for answers, all I see are "You have written a duplicate 
>> class in your module." However, in my case, I did not write the saz-rsyslog 
>> module, I am only using it. It is a puppet-forge approved module with 
>> 635,000+ downloads. And without modifying the module, the issue can 
>> disappear, seemingly without rhyme or reason.
>>
>> -RG
>>
>> -- 
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-users/1ead58c4-ed05-4b03-9bee-6fd576d187f3%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/3b067d75-df51-4a51-840e-d69990b592b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Issue with module from forge - Duplicate declaration Class[Rsyslog]

[Rob Nelson]

RG, typically the Duplication declaration message is followed by some
indicator of the file where it is duplicated and the line number. Are you
receiving that information and maybe snipped it off the end of the message
you included? An alternative might be any sort of `hiera_include()` or
`create_resources()` calls whose arguments may include `rsyslog` more than
once.


Rob Nelson
rnels...@gmail.com

On Wed, Oct 5, 2016 at 3:16 PM,  wrote:

> I installed the puppet module saz-rsyslog from puppet forge.
> I use The Foreman to configure nodes. The Foreman is used by puppet via
> configuration [master] "external_nodes" "/etc/puppet/node.rb"
>
> Since the saz-rsyslog module install, I have been receiving the following
> error off and on (not consistently) across many nodes on a puppet update
> (i.e. puppet agent -t):
>
> "Could not retrieve catalog from remote server: Error 400 on SERVER:
> Duplicate declaration: Class[Rsyslog] is already declared; cannot redeclare
> on node "
>
>
> My nodes are CentOS 5,6,7; and any various number of the nodes may
> experience this issue, but not all of them at the same time.
>
> One day I will see dozens of server with this error, and other nodes not
> having this issue. This may go on for days if I do not touch The Foreman.
> I'll make some changes to host configuration for puppet module class
> parameters in The Foreman - never the saz-rsyslog module though..
> After the changes, half or more of the servers having issue (not all) will
> magically have no problems.
> However, more nodes that did not have issues before, will now experience
> this issue.
>
> Also, this change of events is not directly related to The Foreman host
> configuration changes.
> I can simply perform a puppet module upgrade to a unrelated module (e.g.
> mine-yumconfig). After upgrading the unrelated module, again many nodes
> with this issue will now have it resolved, and different ones not
> experiencing the issue before will now begin experiencing it.
>
>
> The only clue I have is from this posting: http://grokbase.com/
> t/gg/puppet-users/165h0exgez/duplicate-resource-declaration-error
> "... If you do not see the error on every run then it is modulated by
> something that varies between runs. That could be almost anything:
> manifests, data, results of function calls, node facts, or ENC output. ..."
>
>
> Can anyone help me understand this issue, or help me get it resolved
> permanently?
>
> When I search for answers, all I see are "You have written a duplicate
> class in your module." However, in my case, I did not write the saz-rsyslog
> module, I am only using it. It is a puppet-forge approved module with
> 635,000+ downloads. And without modifying the module, the issue can
> disappear, seemingly without rhyme or reason.
>
> -RG
>
> --
> 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/1ead58c4-ed05-4b03-9bee-6fd576d187f3%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAC76iT_tan-L2xS26Jz1gRNVMH4amEBvmqHbQx8hZNUzdp8MAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.