On Wednesday, October 12, 2016 at 4:15:51 PM UTC-5, re-g...@wiu.edu wrote:
> You were right, that catalog file
> 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:
> 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=
> 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.
> 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 could wish
that The Foreman would supply class parameters by hooking the automated
data binding framework instead of by explicit declaration in its ENC
output, but there would be both advantages and disadvantages to that from
the Foreman perspective.
> Nor has this been an issue for nodes performing puppet updates against the
> primary-master puppet server and all the other secondary-master puppet
> servers (I have 3 secondary-masters, 1 local network, and 3 remote networks
> with secondary-puppet servers).
I can only speculate about why you see the errors only on one of your
secondary masters, with the primary and other secondaries never exhibiting
it when building catalogs for the same nodes based on the same manifests,
data, and Foreman configuration. If that's indeed what you see, then the
only possible explanation is that there is something different about the
machine that exhibits the errors. My first guess there would be that the
version of Ruby on which the master and / or The Foreman is running
differs. My second would be that something about the way that saz-rsyslog
configured into The Foreman differs (general configuration, not its use
with any particular node). I'm sure there are other possibilities.
> I cannot configure the class parameters in The Forman in the puppet
> module's class for a node unless the puppet class is assigned to the node.
> I can assign the class (1) directly to the node, or (2) to the node group
> the node is in, or (3) to a class config group that I can assign to the
> node or the node group. I have done #3, the config group, and I assign the
> config group to the highest parent node group all nodes in all networks are
> a member of.
> So when any rsyslog::client class parameters are defined, I receive the
> duplicate declaration error for nodes only in this one remote network.
> Yesterday I was experiencing this duplicate declaration error in another
> one of my remote networks, but it resolved itself magically within 24 hours
> - no one touched The Foreman, and all I did was login and monitor the
I cannot explain why the behavior would vary over time. I have a few
general ideas, but they are too speculative to discuss.
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 view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.