On Thursday, May 19, 2016 at 4:39:03 AM UTC-5, James Denton wrote:
> Hi Greg
> Thanks for the reply, its strange that this is fairly intermittent (works 
> for a couple of hours then fails with the error). I have other puppet 
> classes that also inherit from a base class but these do not fail. The 
> differance between this class and the others that work is that the class 
> show above declares parameters before inheriting the base class. 
> "Worth double-checking that the ENC data doesn't change when the error 
> occurs (if you can catch it)"
> How can I do this (if possible)?
> Thanks!
> On Tuesday, May 17, 2016 at 5:47:37 PM UTC+1, Greg Sutcliffe wrote:
>> It's almost certainly a problem within your puppet code. Foreman only 
>> sends a list of classes (and parameters, together called the ENC data) to 
>> Puppet, which then deals with compiling the catalog, eg:
>> classes:
>>   apache:
>>   ssh:
>>     loglevel: debug
>>   syslog:
>> And so forth. That's generally pretty static; in which case the issue is 
>> likely that what Puppet is evaluating for the ENC data supplied by Foreman 
>> is changing.
>> Worth double-checking that the ENC data doesn't change when the error 
>> occurs (if you can catch it), at which point you can rule out Foreman 
>> entirely.
>> Greg
I am experiencing very similar issues.
In my case I am using an approved module from puppet forge, saz-rsyslog.
And I am not writing any declarations of any kind. Everything is done in 
The Foreman.

I have had a detailed discussion on the puppet-users mail list about my 
Issue with module from forge - Duplicate declaration Class[Rsyslog]

We came to a point in this discussion thread that first points at an issue 
with the saz-rsyslog module, but also *may* point at a possible issue with 
The Foreman.

Here is the issue I submitted with the saz-rsyslog forge module:
Duplicate Declaration Class[Rsyslog] with The Foreman as ENC during catalog 
compilation #237

The *possible* issue with The Foreman is that under certain and uncommon 
circumstances The Foreman can sometimes build a catalog in which subclasses 
can be declared before their parent class. With a some kind of unrelated 
fact/parameter change in The Foreman, or after just waiting, this issue 
will resolve itself.

In this thread you are discussing an intentional declaration.
But in my issue (see my puppet-user thread) the declaration is 
And we think that under uncommon circumstances we cannot determine, The 
Foreman as ENC causes the rsyslog::client subclass to be declared before 
the rsyslog class.

Not only is it unintentional, but my specific environment (1 primary and 3 
secondary masters puppet servers with The Foreman Proxy) shows that it can 
happen on one secondary-node, and not at all on another secondary-master. 
And then hours later this scenario can flip. And at the same time a third 
secondary-master puppet server under The Foreman Proxy server does not ever 
experience the issue.

The issue is never experienced with the primary-master puppet server, to 
which is also the primary The Foreman server.
So perhaps it points to an issue with a The Foreman Proxy server? ... I do 
not know.

Having subclasses declared before the parent class seems to not be an issue 
with many other puppet modules. So that points at an issue with the 
saz-rsyslog module - to which I submitted an issue with the puppet-module 

However, looking back at The Foreman, I wonder if it is not the intention 
that The Foreman as ENC would under these undetermined circumstances 
declare a subclass before the parent class, and then 8-12 hours later 
change to have the parent class declared before the subclass. Something is 
causing that subclass to be declared first in the catalog, and that cause 
may be independent to The Foreman alone - after tracing out the results I 
have experienced.

Keep in mind, if we know this is the issue, I have installed a The Foreman 
Proxy server with secondary-master puppet servers that NEVER have this 
issue. Would this suggest that the issue is with my configuration, and not 
internally to The Foreman? And if so, where would I look to track down this 
If this is not a configuration issue, is this an allowed or intended action 
of The Foreman as I have described - seemingly randomly ordering 
declaration of classes and subclasses?

I appreciate any leads to help track down this issue I have been 
experiencing for many months.


You received this message because you are subscribed to the Google Groups 
"Foreman users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-users+unsubscr...@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.

Reply via email to