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 <javascript:> 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 <javascript:> >
Thank you for your answer. 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. I have posted my findings in this thread: https://groups.google.com/d/topic/puppet-users/0JHrMGuo8YQ/discussion -RG -- 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.
