Matt, I can't speak for exactly what John was implying, but I've been working on something similar recently, and facing more or less the same problems that you're implying below, so I'll give you my take on it.
1) Yes, it means factoring "all" possibly-shared resources out into discrete classes. The definition of "all" is flexible depending on how fine-grained your package management needs to be, and how willing you are to possibly have some "extra" packages floating around. 2) Including modules from the Forge is another beast. At this point, at $work, we're moving in the direction of *only* writing our own modules if there isn't a suitable Forge module. So, we've ended up with a few cases where we have two conflicting modules that can't be used on the same node (usually a Forge module that is intended to replace an older in-house module as it's phased out). The "proper" way to manage this is when you add a Forge module that replaces existing functionality, you should remove any existing declarations of those resources and replace them with a require, or something like that. A specific example... we recently started using the puppetlabs-postgresql Forge module (https://github.com/puppetlabs/puppetlabs-postgresql/). It has a postgresql::lib::python class that installs the python-psycopg2 package (the python postgres driver), and a postgresql::lib::devel class that installs postgresql-devel. So, when we decided we were going to use the new Forge module, we grepped through all of our existing modules, and replaced any Package resources for these packages with "require postgresql::lib::python" and "require postgresql::lib::devel", respectively. I assume I speak for many in saying that I hope that with the ever-increasing usefulness of the Forge, the community begins to converge on a single "canonical" module for a given use case or package. -jason antman On 11/19/2013 02:48 PM, Matt Simmons wrote: > Hi John, > > I'm new around here, but I'm also in the same situation as Tom, who > started this thread. > > I was wondering if you could expound a little bit on the better > solution that you mention. I write what I could refer to as "third > grade puppet", but I'd like to get better. > > When you suggest factoring out these resources into separate classes > and modules, do you mean that, in essence, all possibly-shared > resources should be in discrete modules or classes? How does that jive > with modules included from Puppet Forge? Doesn't that mean refactoring > everything you include there, as well? > > Thanks, and sorry for what I'm sure is an overly-basic question, > > --Matt Simmons > > > -- > You received this message because you are subscribed to the Google > Groups "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/7f66b5b7-6e20-4835-a057-b62c1add08e7%40googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/528CAF44.1050205%40jasonantman.com. For more options, visit https://groups.google.com/groups/opt_out.
