On Monday, December 31, 2012 12:40:26 PM UTC-6, Matthew Barr wrote: > > I'm working with a forge module that specifies & installs a yum repo > before it installs the packages, then goes about it's business. > * package isn't part of a standard repo > > We operate on a policy of minimizing the amount of external repo's we use, > especially on the edge systems. > * I can sync a repo into the central repo server, though. > > I can't imagine we're the only shop that doesn't allow edge servers to > talk to the outside world, so how do other folks deal w/ forge modules that > expect that? >
I'd be inclined to reject the module outright unless it provided a documented mechanism for avoiding or controlling the configuration of a package repo. I am not inspired to confidence in the rest of the module if its author doesn't recognize that configuring a new repo on my systems might not be something I would readily accept. > > What's the best practice for the community? > > Option 1: Don't change the module itself: > One way to deal with this is to use an internal module to override the > repo class, similar to : > You say in a later post that that doesn't work, but I don't see why not. The Yumrepo resource surely is declared by some class, and you should be able to create a subclass of that class that overrides its declaration. If the class in question is parametrized, then you should be sure that it is declared before your subclass. I'm not sure that's much better than modifying the module, though, if it means digging into the module implementation to find the requisite internal class. It's somewhat less likely to break if you update the module, but nowhere near as safe as using the module's documented interface. > > > Option 2: > > modify the module to make the repo optional. > - probably a parameter w/ a default of install. > > > Or I'm sure you could devise other alterations that would be satisfactory. If you are willing to contribute the changes back to the module's project, then this is probably the better approach. There is also option 3: ask the module author to devise and implement a solution instead of changing the module yourself. If you can't contribute your own changes back upstream, then getting upstream to make them in the first place protects you better against breakage in the event of a module upgrade. Also, the person most familiar with the module implementation is the one who implements a solution in this case. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/aXAQVY_ih0sJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
