On Mon, Dec 13, 2010 at 8:01 AM, Jeff McCune <j...@puppetlabs.com> wrote: > +1 I'm really curious about the prior work and experience you mentioned in > the presentation where this is considered an anti pattern in OOP and design.
Tight coupling in general is considered an antipattern in OOP design. Most software engineering classes, for example, cover this early on. See http://en.wikipedia.org/wiki/Coupling_(computer_science) for decent coverage of the topic. Ultimately, whether coupling is good or bad really depends on your (or your groups) coding style, situation, and preferences. I recommend *not* coupling in Puppet for a few reasons, but mainly because the #2 question I see in #puppet on irc is regarding cross-class variable scoping (especially when inheritance is involved). For that reason, I try to steer folks away from using variables across classes - between two bay area puppet camps, many puppet users agreed that 'variable scope is borked' in some way or another. You can better use custom defines to abstract things, in most cases, rather than simply exposing variables. In my experience, I am forgetful, which is why I choose abstraction-via-custom-define first. If you do not abstract, but simply export a variable, you end up with apache configs (for example) that look like this: class mywebapp { include apache::server file { "$apache::server::configpath/mywebapp.conf": ensure => file, source => "puppet:///...", require => Package[apache2], # maybe provides the configpath on disk. notify => Service["apache2"]; } } For there above, there were 3 things I had to remember: First, that there is a variable that has the path to apache config directory. Second, that I had to require the apache2 package (something we assume is defined by apache::server). Third, that I have to notify apache2. If you abstract it away, you can answer "I want apache to have my webapp's config" with: apache::config { "mywebapp": source => "puppet:///..."; } And avoid having to carry around any internal knowledge of the apache module. Presumably apache::config properly requires and notifies as necessary. Should you change any internals to your apache module, consumers of your custom defines probably aren't going to need modification. This is similar to code libraries presenting a consistent external API, while allowing internal changes (bug fixes, improvements) without involving API consumers. -Jordan > Thanks, > -- > Jeff McCune - (+1-503-208-4484) > On Dec 13, 2010, at 2:42 AM, Dan Bode <d...@puppetlabs.com> wrote: > > Hi Jordan, > > Thanks for forwarding these slides. They are for the most part > self-explanatory. I would like to hear more about your motivations for not > recommending the coupling together of modules with namespaced variables. > (slides 8,9) > > thanks > > Dan > > On Sat, Dec 11, 2010 at 7:10 PM, Jordan Sissel <j...@semicomplete.com> wrote: >> >> Howdy folks! >> >> I gave a presentation this week to some fellow puppeteers. It covers: >> >> * Style >> * Truth (deployment truth, machine truth, extlookup, rightscale tags, etc) >> * Nodeless puppet (pure fact-driven manifests, no nodes defined) >> * Masterless puppet (no puppet master) >> * Exported resources (nagios, sshkeys, etc) >> * Exported custom defines (for nagios, really useful) >> >> Printable/searchable: >> >> http://semicomplete.com/presentations/puppet-at-loggly/puppet-at-loggly.pdf.html >> Actual slideshow: >> >> http://semicomplete.com/presentations/puppet-at-loggly/puppet-at-loggly.html >> >> The slides have many example puppet manifest snippets and should be >> mostly consumable without me speaking in front of them. I hope you >> find them useful! >> >> -Jordan >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
