Sorry to reply to myself.. but option #1 doesn't work. (It works for resources, but not classes. Silly me.)
So: should forge modules use repo's explicitly? or is there already a standard design pattern that implements a parameter for repos? else… I guess I'll end up writing one :) On Dec 31, 2012, at 1:40 PM, Matthew Barr <[email protected]> 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? > > 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 : > > > class internalJenkins > { > include jenkins::repo > > include internalJenkins::repo # Inherits jenkins::repo > } > > class internalJenkins::repo inherits jenkins::repo { > yumrepo { "jenkins": > baseurl => "http://localrepo/jenkins";, > descr => "Jenkins local repo", > enabled => "1", > gpgcheck => "1", > mirrorlist => absent, > gpgkey => > "http://localrepo/jenkins/jenkins-ci.org.key";, } > } > > > Option 2: > > modify the module to make the repo optional. > - probably a parameter w/ a default of install. > > > > > Matthew Barr > Technical Architect > E: [email protected] > AIM: matthewbarr1 > c: (646) 727-0535 > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
