On Thu, Oct 02, 2014 at 01:39:09AM -0700, Chris Lee wrote: > We try not to use stages at all, unless absolutely necessary and we would > love to avoid them if we could.
Have you tried collectors+tagging and chaining? We've had good results with those. https://docs.puppetlabs.com/puppet/latest/reference/lang_collectors.html https://docs.puppetlabs.com/puppet/latest/reference/lang_relationships.html#chaining-arrows https://docs.puppetlabs.com/puppet/latest/reference/lang_tags.html When dependency cycles come up it's mostly because we're trying to manage related resources in separate modules and it's harder to keep track. The infamous example is the loop created by managing a service in a servicename module, but then having a security module fiddling with service-related items. (Rather than having the security requirements built right into the original servicename module.) > Our puppet code is used on around ~3000 machines in a heterogeneous > environment of both various hardwares, os boot systems and applications, > so at times its an unnecessary evil > > It is my understanding that tidy now now creates a dependency on the file, > but since this is run in the beginning, the tidy on the files which are > created in post creates a loop. For all the other times we use tidy I was > able to get around by splitting the tidy from the classes and simple > including them, this is the last one I cant seem to get around. I did find > another post about this and puppet 3, but no solution > > https://ask.puppetlabs.com/question/13431/how-do-i-work-around-puppet-3-semantics-change/ > > Unfortunately we have way to many variables, and while direct requires > might be possible it would mean an entire rewrite of ~ 4 years of code, > and many times we have run into conflicts anyway which finally forced us > into this. > Mostly the idea is that our (systems admin) configuration is run in main, > specific user requirements are configured in apps, and only after all of > that, do we declare the machine usable. Finally we ensure that things like > puppet are running, where prior to that on a broken system it wouldn't be > required anyway, and then apply certain safety checks, as with this cron > which does a daily check to ensure puppet hasn't been disabled and mails a > report which we can compare with puppet dashboards output. > > With out the stages this would literally require hundreds of "if defined" > statements due to all the various configurations available. > > The "File[/etc/cron.d/puppetcheck.puppet.cron] -> Tidy[/etc/cron.d]" > relationship is from the new design of tidy as explained in the post I > linked above. The code I posted is simple called in a class that is set to > stage post. > > -- > 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 [1]puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > > [2]https://groups.google.com/d/msgid/puppet-users/8972ab55-6b62-499c-bd58-eb82d5593192%40googlegroups.com. > For more options, visit [3]https://groups.google.com/d/optout. > > References > > Visible links > 1. mailto:puppet-users+unsubscr...@googlegroups.com > 2. > https://groups.google.com/d/msgid/puppet-users/8972ab55-6b62-499c-bd58-eb82d5593192%40googlegroups.com?utm_medium=email&utm_source=footer > 3. 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/20141002162719.GA18241%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
