On Thu, Jan 26, 2012 at 6:19 AM, jcbollinger <john.bollin...@stjude.org>wrote:
> > > 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. > It's actually not that bad at all from past experience when all the content is being written in-house, even if the authors are organizationally, politically and geographically disperse. If you have dependencies upon foreign content you didn't author, express it at the class level. This allows the other authors to refactor their own classes internally, and not break your dependencies. If you can't do this, one or both sides need to do refactoring so that it's possible. If you're building content you expect others to use more than once within a given catalog, provide it in the form of defined types with well-named parameters. You do need to have a robust release process in place along the lines of the classic dev -> test -> prod environments. If your teams push out change at significantly different rates, you may need to break up environments more to allow for this flexibility. 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. > +1 There are some things we could all do collectively to improve the situation, particularly around pre-commit hooks to version control. Functionality I've found useful in the past here was: * check whether the changed manifests parse * verify whether foreign class dependencies are fulfilled * verify whether references to file sources actually exist etc etc -- Nigel Kersten Product Manager, Puppet Labs -- 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.
