On Jan 25, 10:53 am, Jo Rhett <jrh...@netconsonance.com> wrote: > On Jan 25, 2012, at 8:30 AM, Nick wrote: > > > But then I have to anticipate every possible value of $shell and define > > resources for them. Anything which is not defined like this is not usable > > within the scheme, because there will be no file resource to realize and > > require. And of course, it also means nothing else can say anything about > > any > > of these files without blowing up, because my code "owns" them. > > > So far as I can see, this property of resources makes it hard to write > > self-contained and reusable modules, and this is frustrating. > > I just want to say +1 to this. I have found Puppet to be a wonderful way to > deeply tie all your automation to an exact known configuration of hosts, but > pretty much useless for dealing with situations in a generalized fashion. It > is hard enough to track all the dependencies on modules being written by > different people within the same team. I cannot image the pain which must be > felt by people who have modules written by geographically and politically > disperse teams.
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. That's not to deny that there is room for Puppet to improve here, but I suspect there is less room than you suppose. 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.
