On Feb 2, 4:42 pm, Jo Rhett <jrh...@netconsonance.com> wrote: > >> On Jan 26, 2012, at 6:19 AM, jcbollinger wrote: > >>> For the most part, I think this reflects the difficulty of the > >>> underlying problem more than any inadequacy of Puppet. If multiple > >>> independent subsystems place different demands on the same resources, > >>> then you have a mess to sort out no matter what tools you use to do > >>> it. On the other hand, if multiple independent subsystems place the > >>> same demands on certain resources, then that's pretty easy to handle, > >>> with Puppet or otherwise. > > On Jan 26, 1:22 pm, Jo Rhett <jrh...@netconsonance.com> wrote: > >> I disagree. I have about 12 different modules, any combination of which > >> may be applied to a given system, all of which need to ensure that sshd is > >> installed and running on a system. They all have a single, common need. > >> However, some of those modules also run on systems where we don't need to > >> ensure that sshd is running. The solution to this is an interlocking maze > >> of module dependancies which is downright terrifying. > > On Feb 1, 2012, at 6:26 AM, jcbollinger wrote: > > > > > > > > > You seem to be describing my former case rather than my latter one, at > > least with respect to nodes that don't need (and apparently don't > > *want*) sshd to be running. All the same, were I faced with a problem > > of that sort I would probably take this approach: > > > 1) Factor the ssh[d] management into its own module. > > 2) Avoid using any parameterized classes in the ssh module, or at > > least in its external interface. > > 3) Instead, have the ssh module use external data to determine node-by- > > node or role-by-role whether sshd should be running. > > 4) Make other modules 'include' or 'require' the appropriate classes > > of the ssh module, as needed. > > > With that, all the modules depend on the ssh module, but they do not > > depend on each other, at least not for this purpose. It's clean and > > simple. Enabling that result is the overarching benefit of the > > ability to assign the same class to a node multiple times. > > That simply doesn't work, because you are basically asking the ssh module to > have all the logic inside it for whether or not certain other classes need > it. As expressed, it would require duplication of all the if/then in the > other modules to be duplicated within this module. That's simply not > practical in a large or diversified team.
How do you figure that? I repeat: "OTHER MODULES 'include' or 'require' the appropriate classes of the ssh module" (emphasis added). That is, the classes that need ssh (as THEY decide) 'include' or 'require' the appropriate classes of the ssh module. This is natural and very maintainable, and it does not require the ssh module to know anything about other modules. To complete the picture, where needed "the ssh module use[s] EXTERNAL DATA to determine node-by-node or role-by-role whether sshd should be running" (emphasis added). That might in fact not be needed anywhere, but if used it serves to *reduce* conditional logic in your manifests and to *remove* inter-module coupling. In particular, it does not require the ssh module to know which nodes or which roles should have sshd running. It only requires the ssh module to know the node or the node's role[s], from which it *looks up* whether sshd should be running. That may be very different from your current design, but the design concept is sound. In fact, it's the soundest Puppet design pattern I know that does not rely on an ENC (though it works fine with an ENC, too). I'd even say it's what Puppetlabs should have embraced and promoted instead of parameterized classes. Nevertheless, if you use an ENC then you also have the option of putting the burden there. That you will do so seems one of the assumptions behind Puppetlabs's current style recommendations, as those call for avoiding classes declaring (or 'include'ing or 'require'ing) other classes. Therefore, that approach necessarily involves moving all the messy conditional logic to the ENC and / or to external data, or at any rate out of the dependent classes themselves. This is the only viable option I know for shared, parameterized dependencies. You can mix those two approaches to some extent, if you're careful, but what you must *not* do -- what it sounds like you are doing -- is to allow any two classes to each declare / include / require the same parameterized dependency, *even conditionally*. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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.
