On Jan 26, 1:22 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. > > 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.
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. > You can't import because of redefinitions. You yourself know well and deeply > the issues involved with calling the same class from different places with > different parameters. It is nearly impossible to get there from here. Parameterized classes do make it very difficult to get there from here. That's one of the key reasons why I avoid them like the plague, and why I urge others to do so. But you *can* get there from here (for a wide variety of "heres"), and it doesn't have to be hard. > The ability for puppet to say "oh, I've seen this definition before and it's > exactly the same so that's not an error" would be a tremendous improvement. I wouldn't object to that. As a practical matter, I think one would have to broaden it to cover all resources rather than only definitions, but that would be fine with me. It might even ease the problem of parameterized classes somewhat. HOWEVER, I wouldn't be eager to rely on such a feature. I can see it all too easily producing a maintenance nightmare when one of perhaps many definitions of the same resource needed to be changed. If many resources were multiply-declared like that then the manifest set would likely be an unmaintainable morass. In the end, then, I suspect I would regard duplicate resource declarations much as I do parameterized classes: as an inferior and inherently problematic solution to the problem it addresses. Like parameterized classes, it would have the advantage of being fairly intuitive and relatively easy to write, and it would adequately address the problem it is targeted at. Also like parameterized classes, however, it would carry its own new problems that, for me, would outweigh those advantages. 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.
