I have posted this on both Puppet users group and here as im not sure if
this is an error with Puppet or Foreman.
I've been having the following issue when inheriting a base class into
another class that requires a resource file to be overwritten, im not sure
if this is a puppet or Foreman error though.
The error i receive is:
Could not retrieve catalog from remote server: Error 400 on SERVER:
Duplicate declaration: Class[Baseconfig::Syslog] is already declared;
cannot redeclare on node test.xyz.com
The error is very intermittent as it will be ok for a few hours or more of
puppet runs and then return.
The Class baseconfig::syslog is not being inherited in any other class or
module other than the one class that requires that file resource to be
overidden and looks like this:
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.
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.
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
unintentional.
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
author.
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
issue?
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.
-RG
···
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
>>
>
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.
···
On 14/10/16 22:54, re-glaue@wiu.edu wrote:
> In this thread you are discussing an intentional declaration.
> But in my issue (see my puppet-user thread) the declaration is
> unintentional.
> 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 author.
>
> 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.
I was incorrect in thinking The Foreman was used to assemble the resulting
catalog given to the puppet agent. Instead The Foreman provides a YAML ENC
output that the puppet server reads in to assemble the puppet catalog given
to the agent. I found both the ENC output and the Catalog output files on
the Foreman/Puppet servers, which led me to a conclusion.
I have confirmed that the The Foreman, and The Foreman Proxy are outputting
the exact same ENC yaml.
But the Primary master puppet server and the Secondary master puppet server
are creating catalogs that are not the same.
The classes are not in the same order on the secondary puppet master as it
is in the primary puppet master.
···
On Monday, October 17, 2016 at 2:53:12 AM UTC-5, Dominic Cleal wrote:
>
> On 14/10/16 22:54, re-g...@wiu.edu wrote:
> > In this thread you are discussing an intentional declaration.
> > But in my issue (see my puppet-user thread) the declaration is
> > unintentional.
> > 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 author.
> >
> > 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.
>
> 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.
>
> --
> Dominic Cleal
> dom...@cleal.org
>
